Project

General

Profile

Anomalie #14707

[Contribution correction CODE] Test custom $_SERVER['SERVER_ADDR'] et infrastructure

Added by Support Maarch over 1 year ago. Updated 11 months ago.

Status:
Développé / Analysé (S)
Priority:
2-Sérieux
Assignee:
Target version:
Start date:
08/31/2020
Due date:
01/11/2021
Tags Courrier:

Description

Bonjour,

Ce ticket a pour vocation d'entamer une discussion sur l'opportunité qu'il y aurait à éliminer, dans Maarch Courrier, un test au niveau du code qui se révèle particulièrement ennuyeux dans des situations de production sur une infrastructure moderne.
Ce bout de code est présent depuis les premières versions de Maarch Courrier et l'est toujours dans le code de la 20.03.7 par exemple. Il se situe au niveau du fichier class_core_tools.php, en particulier dans la fonction suivante (lignes 1656 à 1692) :

public function get_custom_id()
{
    if (!file_exists($_SESSION['config']['corepath'].'custom'.DIRECTORY_SEPARATOR.'custom.xml')) {
        return '';
    }
    $linkToApps = false;
    $arr = explode('/', $_SERVER['SCRIPT_NAME']);
    if ($key = array_search('rest', $arr)) {
        unset($arr[$key]);
    }
    $arr = array_values($arr);
    for ($cptArr = 0; $cptArr < count($arr); ++$cptArr) {
        if ($arr[$cptArr] == 'apps') {
            $linkToApps = true;
        }
    }
    if ($linkToApps) {
        $path = $arr[count($arr) - 4];
    } else {
        $path = $arr[count($arr) - 2];
    }

    $xml = simplexml_load_file($_SESSION['config']['corepath'].'custom'.DIRECTORY_SEPARATOR.'custom.xml');
    foreach ($xml->custom as $custom) {
        if (trim($path) != '' && isset($custom->path) && $custom->path == trim($path)) {
            return (string) $custom->custom_id;
        }
        if ($custom->ip == $_SERVER['SERVER_ADDR']) {
            return (string) $custom->custom_id;
        }
        if ($custom->external_domain == $_SERVER['HTTP_HOST'] xor $custom->domain == $_SERVER['HTTP_HOST']) {
            return (string) $custom->custom_id;
        }
    }

    return '';
}

En effet, afin de charger le custom à prendre en compte (le cas échéant) il teste la correspondance entre l'ip (à renseigner manuellement) dans le fichier custom.xml et l'ip du serveur renvoyée par la variable de serveur $_SERVER dans $_SERVER['SERVER_ADDR']

Je n'ai jamais vraiment compris l'intérêt de ce test, peut-être a-t-il eu une utilité dans la prise en compte de customs multiples sur une même instance comme semble le suggérer la boucle for dans lequel le test s'inscrit ?
En tous cas je ne suis pas bien sûr qu'il y ait un cas pratique et courant qui justifient les ennuis que causent ce test.

Les ennuis en question ne devaient pas se manifester il y a quelques années avec les premières versions de Maarch Courrier étant donné que la norme d'alors était plutôt un serveur applicatif bare metal et dédié ayant vocation à tourner plusieurs années, les mises à jour étant effectuées itérativement.
L'ip du serveur Apache ne devait donc théoriquement pas changer et était à renseigner une fois à l'installation dans le fichier custom.xml.

Il est difficile d'ignorer qu'aujourd'hui le contexte d'exploitation a changé : les infrastructures sont de plus en plus virtualisées et particulier l'état de l'art tend à faire de la containérisation et de l'organisation en micro-services le mode d'exploitation principal.
Le MTES, pour de multiples raisons, a fait le choix d'une infrastructure containérisée pour l'exploitation de Maarch Courrier. Dans ce contexte les containers des diverses instances de l'application peuvent être amenés à être redemarrés, migrés de machine physiques par un load balancer, etc.
Ces opérations réalisées soit automatiquement selon les règles d'orchestration de l'infrastructure containérisée, soit volontairement (mise en place d'un environnement type dév pour des tests de paramétrage technique, instance de recette à très courte durée de vie, etc) ont vocation a être transparentes pour les utilisateurs mais le fait que chaque nouveau container se voit attribué une ip différente au sein réseau virtuel de l'orchestrateur de containerisation pose problème vis-à-vis du code mentionné ci-dessus.

Nous nous retrouvons donc avec des interruptions de service sur des environnements de production, aléa sévère, ou avec des opérations manuelles de mise à jour des fichiers custom.xml sans plus-value évidente sur les autres environnements.
Il n'est pas évident de "tourner autour" du problème : une approche via un script lancé automatiquement à l'exécution du container applicatif qui essaye de récupérer l'ip du serveur a été tentée mais il ne fonctionne pas systématiquement (pas forcément la même interface réseau montée à chaque fois selon le réseau hôte). De même il est possible de rendre le fichier custom.xml un peu moins pénible à éditer dans un contexte containérisé en montant le fichier sur le système hôte afin d'y accéder facilement mais ça nécessite toujours une intervention manuelle et s'oppose aux bonnes pratiques en matière de containérisation.

En bref nous en sommes venus à considérer cet irritant comme une vraie anomalie, surtout au regard du peu d'utilité apparente de ce test et des impacts très négatif que cela a en production.
Il sera possible d'opposer que Maarch n'offre aucune compatibilité particulière a priori pour les infrastructures containérisées mais il serait opportun de prendre ce problème en compte pour l'avenir du produit afin que ce dernier ne se retrouve pas à contre-courant de ce qui est une tendance générale de l'état de l'art.
Par ailleurs ce problème se pose pour tout type d'infrastructure à courte durée de vie, pas uniquement pour la containérisation : c'est le cas par exemple pour des instances de tests déployées par Ansible sur des VPS "jetables".

En vous remerciant d'avance pour votre retour sur ce sujet.

History

#2 Updated by Emmanuel DILLARD over 1 year ago

  • Status changed from A traiter to Etude planifiée

#3 Updated by Emmanuel DILLARD over 1 year ago

  • Status changed from Etude planifiée to 17
  • Assignee changed from Support Maarch to Ines MKACHER

Possible d'avoir le fichier custom.xml.

Des pistes pourront être fournies pour l'adaptation.

#4 Updated by Emmanuel DILLARD over 1 year ago

  • Target version changed from 19.04 (CUSTOM) to 19.04 (Support sécurité)

#5 Updated by Support Maarch over 1 year ago

  • Status changed from 17 to A traiter
  • Assignee changed from Ines MKACHER to EDI PO

Bonjour,

Ci-dessous le contenu de notre fichier custom.xml :

<?xml version="1.0" encoding="utf-8"?>
<root>
    <custom>
        <custom_id>meem</custom_id>
        <ip>127.0.0.1</ip>
        <external_domain></external_domain>
        <domain></domain>
        <path></path>
    </custom>
</root>

Le nom de notre dossier de custom est meem et l'ip par défaut 127.0.0.1 était remplacée au démarrage par celle calculée plus ou moins heureusement par un script jusqu'à mon fix récent.

Bien cordialement,

#6 Updated by Emmanuel DILLARD over 1 year ago

  • Due date set to 01/11/2021
  • Status changed from A traiter to Etude planifiée

#7 Updated by Emmanuel DILLARD over 1 year ago

  • Status changed from Etude planifiée to 17
  • Assignee changed from EDI PO to Ines MKACHER

Mettre l’alias et non pas IP DANS DOMAIN ou external domain.

Voir avec l’intégration.

Note : le code a changé depuis.

#8 Updated by Emmanuel DILLARD over 1 year ago

  • Priority changed from 1-Majeur to 2-Sérieux

#9 Updated by Emmanuel DILLARD about 1 year ago

  • Status changed from 17 to Développé / Analysé (S)

#10 Updated by Emmanuel DILLARD 11 months ago

  • Project changed from Backlog to Backlog Courrier
  • Target version changed from 19.04 (Support sécurité) to 19.04 (Sécurité)

Also available in: Atom PDF