Recueil des mauvaises pratiques constatées lors de l'audit de sites Drupal 7

Drupal : Best Worst current practice
Par Frédéric G. Marand
1/66 • Drupal : worst current practice • © OSInet

Drupagora
Paris le 14 novembre 2014

DRUPAGEDDON

Introduction
CAS D'ÉCOLE : DRUPAGEDDON
LES DONNÉES
https://www.drupal.org/SA-CORE-2014-005
https://www.drupal.org/PSA-2014-003
EN PRODUCTION : un site qui ne suit pas les bonnes pratiques a
des difficultés à appliquer la MàJ rapidement
• Combien de minutes avant de déployer sur votre site ?
• Pourquoi si longtemps ?
• Comment améliorer ?
• Comment gérer les suites ?

OSInet,
UN REGARD SPÉCIFIQUE DANS
L’ÉCOSYSTÈME DRUPAL

Introduction
CONTRIBUTEURS AUX PROJETS LIBRES
OSInet
• Contributeurs Drupal depuis
2005
• 100 % de l’effectif est
contributeur Drupal core 8
• Autres contributions depuis 94 :
Apache, Beego, Doctrine ODM,
FirebirdSQL, MongoDB,
Monolog, Samba, Silex…
Frédéric G. Marand
• (Co-)auteur et (co-)correcteur
de plusieurs Security Advisories
Drupal
• Mainteneur Drupal 7 core XML-RPC
• Mainteneur des contribs
(References…)
http://www.osinet.fr
http://bit.ly/drupalosinet
@OSInet
http://drupal/u/fgm

Introduction
ACTIVITÉ
AUDIT CONSEIL
LEAD DÉV ARCHITECTURE

Introduction
L’AUDIT TECHNIQUE DRUPAL
Problèmes récurrents motivant les audits :
• Délais
• Performance
• Sécurité (réponse aux pénétrations)
Les principales erreurs se répètent par ignorance :
évitez-les

Introduction
Quand les erreurs sont-elles
constatées ?
• Durant l’acquisition
• Durant la réalisation
• Durant le fonctionnement
• Lors des visites anonymes
• Lors de l'utilisation en connecté
• Lors des opérations d'exploitation

Introduction
Quelles sont les erreurs les plus
fréquentes ?
• Délais (coûts) excessifs de réalisation
• Régressions durant le développement de code
• Coûts excessifs en infrastructure
• Failles XSS et autres
• Performance front insuffisante
• Performance back insuffisante

Introduction
Qui est source d’erreurs ?
• L’agence réalisatrice : mauvaises techniques de réalisation
• Le studio graphique : maquettes ignorant les spécificités de
build Drupal
• L’hébergeur : ignorance des contraintes spécifiques de
Drupal
• La communauté Drupal et Open Source en général : peu de
modules / thèmes (aucun ?) ont le même niveau d’exigence
qualité que Drupal core
• Le donneur d’ordres : analyse insuffisante des besoins,
exigences inappropriées

BUY

Propriété intellectuelle
Bloquer sur cession de propriété vs concession de licence
• Définition du besoin
• Certification de conformité (compliance)
Ignorer l’impact de la viralité de la GPL sur les projets
Drupal
• Code source PHP, JS
• Assets graphiques
• Contenus
• Look-and-feel
PS I am not
a lawyer.
Achat

Achat
Le cas des appels d’offres publics
• Difficulté à déclarer un marché infructueux même
quand il devrait l’être
• Ne pas être à jour sur le CCAG-PI / CCAG-TIC et
les circulaires associées
• Définition de l’objet du marché : site vs logiciel
• Procédures de recette : spécification vs agilité

Achat
Choix des prestataires : principaux
problèmes
Agences de communication
traditionnelles
➔ Pas assez techniques pour
les projets importants
SSII (ESN) / SSLL (ENL)
traditionnelles
➔ Pas assez créatives pour
les projets importants
Spécialistes AMOA
➔ Retour sur coût difficile à
évaluer avant un premier
échec
Drupalshops
➔ Pas assez disponibles,
problèmes d’agrément
dans les grands comptes,
pas assez de
connaissances autres

BUILD

Maîtrise
d'ouvrage

Build
Ne pas savoir choisir sa version core : 6, 7,
8 et son type de développement
— Ces temps-ci…
• Projets courts, à courte durée de vie (événementiel, one-off) :
7, build basique
• Projets plus longs, livrés début 2015, destinés à une refonte
assez rapide : 7, build best practice (cf session Best Practice)
• Projets plus longs, livrés mi-2015, destinés à un cycle de vie
plus long : 8, build best practice
• Évoluer les sites bloqués en 6 en mode découplé/composant.
• Ne plus lancer de nouveaux projets en 6

Build
Ne pas savoir définir ses choix en matière
de versions contrib
« STABLE ONLY » : de plus en plus, dans les projets
Drupal, « stable » est synonyme d'« obsolescent »
⇒ coûts de maintenance adaptative
« ANYTHING GOES » : risque que les constructeurs
utilisent des modules expérimentaux, sans cycle de
mise à jour disponible, voire non maintenus
⇒ coûts de maintenances corrective et adaptative

Build
Et plus...
• Ne pas réceptionner au fil de l’eau — pendant les
itérations — pour intercepter rapidement les
divergences (héritage du cycle en V)
• Lors des réceptions d’itération, ne pas vérifier
l’état de propreté du site (installation from scratch
possible, absence de doublons fonctionnels, de
traces de composants abandonnés...)

Processus de
développement

Build
Ne pas utiliser de gestionnaire de versions
...DU TOUT (dernier en date observé : ce mois-ci !)
...EFFICACEMENT :
• code commenté en production au lieu d’être dans
une révision
• commentaires de commit inutilisables
• commits trop espacés
• pas de process de branching réfléchi (eg: git flow,
github flow…)

Build
Créer un site par accumulation de
modules contrib à portée limitée
• Souci additionnel de qualité, fragilité, maintenance
et MàJ
• Sauf dans le cas de couverture à 100 % de la
fonctionnalité, l’adaptation est à long terme plus
coûteuse qu’un spécifique

Build
Créer un site par accumulation de
changements, sans mécanisme de
déploiement
• Génération des fichiers
• Drush Makefile / Composer :
– Avantages: dépôt léger, MàJ permanente
– Inconvénients : dépendance sur la disponibilité du réseau, non-compliance,
MàJ permanente = risque de casse
• Vendoring :
– Avantages : disponibilité, rapidité, compliance
– Inconvénients : défaut de MàJ automatique, dépôt lourd
• Profil(s) d’installation Drupal
• Chargement des données par migration (Migrate API)

Build
Hacker core/contrib
• Rarement nécessaire : le plus souvent, c’est un
manque de connaissances
• Si nécessaire, committer les patches de façon
reproductible (ex : drush makefile, répertoire
patches …)

Build
Développer en PHP brut, sans passer par
les API Drupal
Exemples typiques, souvent sources de problèmes
de sécurité :
• API de bases de données natives au lieu de DB
API/Schema API (injection SQL)
• Accès aux superglobals, notamment $_GET (XSS)
• Stockage de données privées dans $_COOKIE au
lieu de $_SESSION (mascarade)
• Actions de modification sur GET sans jeton ou
formulaire non protégé (CSRF)

Build
Développer sans visibilité des erreurs au
niveau maximal (error_reporting = -1)
• Les notices et warnings s’accumulent durant le
développement
• En fin de projet, on constate des masses
d’insertions dans dblog (2014 : 1500 insertions
watchdog/seconde sur un site) et plus le temps de
corriger donc on le désactive
• Du coup, plus de suivi des vraies alertes

Build
Tests de recette et montée en charge
Ne pas faire de TMC : tout
va bien sur les postes de
développement / recette
Tester sur un
environnement non iso-prod
Tester depuis un poste
local, notamment le serveur
front
Tester uniquement en
anonyme

Build
Négliger la prise en compte des pratiques
permettant l’internationalisation
• Formats en dur (dates, nombres, monnaies) au lieu
des API Drupal
• Assemblage de chaînes traduites :
exemple t($a) . t($b)
• Chaînes de texte non traduites dans les templates
et modules

OWN

Hébergement

Confondre
hébergement et
infogérance
Un site de production a
besoin d’un infogérant
(services système) et
non simplement d’un
hébergeur (location de
matériel et
infrastructure pour le
ranger)
• Backups
• Configuration, MàJ et
monitoring du serveur
Web et ses modules,
PHP et ses extensions,
bases de données,
serveurs de cache,
serveur de file
d’attentes, etc
Own

Déployer sans cache
d’opcodes ou sans
monitoring
• PHP 5.3 ou 5.4 : APC,
PHP 5.5 : Opcache
• Monitoring : apc.php,
ocp, opcache-status,
opcache-gui…
Own

Déployer un
Memcached sans
comprendre sa
configuration
Own
• settings.php : clusters, bins, préfixe...
• extension, persistence, stratégie de
hashing, ucp/tcp, text/binaire…
• slab size
• Monitoring: phpmemcacheadmin,
memcache.php…
• Un memcached mal réglé peut être
beaucoup plus lent qu’un cache en base
de données
• Typique :
• entrées > 1 Mo et slab size par
défaut
• multisites sans préfixe,
• bins saturés,
• mélange chaud/froid, gaspillage
d’allocation
• Documenté à partir de Drupal 7.33

Déployer sur un
système de fichiers
inapproprié
• Écritures synchrones :
NFS système sans
accélérateur
• lstat() lents
provoqués pour
include_once -> tune
realpath cache
Own

Maintenance
applicative :
corrective et
adaptative

Own
Ne pas appliquer les MàJ de sécurité dans
les délais
Pourquoi ne pas les
appliquer ?
• Rigidités entre mainteneur et
infogérant (procédures de
déploiement)
• Absence de réactivité du
mainteneur
• Difficultés de MàJ :
typiquement conséquence
des hacks core/contrib

Own

Travailler sans
logger
Own
CAUSES TYPIQUES :
• Désactivation de dblog
faute d’avoir codé à
error_reporting
élevé, pour faire face aux
masses de notices
• Absence d’utilisation de
syslog ou d’un mécanisme
plus tolérant comme
mongodb_watchdog

FRONT :
PERFORMANCE

Gestion de
cache

Cache de pages
interne
• Cache interne désactivé
(cache enabled :
décoché)
• Expiration trop courte :
limitation à la scalabilité
interne (liée à l’infra
propre) et non externe
(web scale)
Front

Pages non cachables • Écriture dans $_SESSION ou
$_COOKIE pour les anonymes
• démarrage de session qui
marque la page non cachable
• génération complète au hit
suivant
• grosse limite de scalabilité
ramenant les anonymes à peu
près au niveau des connectés
• Utilisation de Varnish et/ou d’un
CDN ou autre reverse proxy,
mais émission par le code d’en-têtes
de non-cachabilité
• suppression de la scalabilité
externe
• inutilité complète de ces outils
Front

Désaccord sur la
durée du cache
• Technique → long
éditorial → court
• En l’absence d’une
stratégie claire, forte
probabilité d’une
absence de prise en
charge technique valide
Front

Front
Agrégation des assets
• Désactivée pour le CSS et/ou le JS
• généralement, ce n’est pas un oubli, mais le
prestataire indique que le site ne fonctionne pas
avec : c’est le signe d’une erreur de réalisation, le
plus souvent pour le code JS
• Simple : il y a des mécanismes d’agrégation
avancée plus efficaces, comme le module advagg,
notamment si on utilise un CDN avec le module
CDN

Front
Domain sharding
• ABSENCE :
• Les cookies sont émis par les clients sur les
requêtes d’asset
• Avec Varnish ou un autre reverse proxy : nécessite
un VCL spécifique pour permettre de les ignorer et
servir quand même de cache
• EXCÈS : multiplication des requêtes DNS pour les
clients

Et tous les problèmes du back office pour les
pages non cachées...

BACK

Back
Requêtes sortantes durant le cycle de
page
• La durée des pages devient > au temps de réponse
de la ressource externe et peut bloquer
• Core:
• update (uniquement pour les admins et sur
certaines pages)
• aggregator, si poormanscron n’a pas été désactivé
SOLUTION Consommer dans des scripts CLI lancés par
cron ou, mieux, depuis un worker de messaging externe
(ex : Beanstalkd)

Back
Pic de charge inexpliqué après une
longue durée sans problème
TYPIQUE Utilisation d’un memcached avec l’erreur
t($var) et la taille de cache_locale vient de dépasser 1
Mo
VARIANTE Sur un site en évolution, une nouvelle version est
beaucoup plus lente en production qu'en développement
CONFIRMATION Déboguer l’utilisation du cache avec
Heisencache ou XHprof
SOLUTION À court terme, augmenter la slab size, et
rapidement corriger pour revenir à une taille normale

Site
globalement
lent sans pic
spécifique

Back
Cache de blocs désactivé
CAUSE Typiquement un ou plusieurs modules de
node_access
CONFIRMATION Configurer stark pour n’avoir que
le bloc contenu, basculer dessus momentanément, et
comparer : il devrait être considérablement plus
rapide
SOLUTION 1 Repenser la logique de contrôle
d’accès aux données
SOLUTION 2 Introduire du cache dans chaque bloc

Back
Cache de données
Too much of a
good thing is
wonderful
PROBLÈME 1 Cache désactivé — courant sur les
sites construits sur Views et Panels
MALGRÉ le cache intégré de Views (durée) et Views
Content Cache (invalidation)
ET MALGRÉ Panels Hash Cache
PROBLÈME 2 Utilisé à niveaux multiples
⇒ Cache de données, puis de fragments, puis
d’assemblages, puis de rendu, puis de blocs … = n aller-retours
vers le serveur de cache là où un seul suffirait
DIAGNOSTIC Heisencache (PerformanceSubscriber)

Back
Cache de variables toujours en MISS
CAUSE TYPIQUE Un variable_set dans un hook du cycle
de page : hook_boot / hook_init / hook_exit, function
de shutdown, etc
ORIGINE Confusion entre settings/config/state
(formalisés en D8)
DIAGNOSTIC var_dump(debug_backtrace(FALSE))
dans variable_set() et remonter la pile pour trouver le
coupable
VARIANTE Autres caches toujours en MISS
SOLUTION GÉNÉRALE Heisencache (WriteSubscriber)

Back
Trop grand nombre de requêtes SQL
DIAGNOSTIC devel.module ou utiliser les
fonctions de trace de l’API DB
SOLUTION Manuelle

Back
Trop grand nombre d’interventions de
hook, notamment sur les nodes
CAUSE TYPIQUE Trop de modules
SOLUTION Réduire le nombre d’implémentations
en repensant la logique fonctionnelle
HACK hook_module_implements_alter()
pour supprimer les situations connues comme ne
pouvant donner lieu à une modification en pratique
— difficile et fragile, mais résultats rapides

Back
Autres problèmes courants
Opérations en boucle (node_load, node_view) au
lieu d’opérations multiples
(node_load_multiple)

CONCLUSION

Conclusion
La clef : compétence
• Compétence du maître d'ouvrage (MOA) :
déléguer n’est pas ignorer ⇒ se faire bien
entourer et suivre son projet

Conclusion

Conclusion
La clef : compétence
• Compétence du maître d'ouvrage (MOA) :
déléguer n’est pas ignorer ⇒ se faire bien
entourer et suivre son projet
• Compétences internes ou AMOA
• Compétence du maître d'oeuvre (MOE)

Conclusion
Mesurer pour agir
• Savoir quoi mesurer
• Savoir sur quoi agir
selon la mesure

Conclusion
Adapter
Adapter les pratiques à la taille du projet
En-dessous de quelques milliers de visites/jour,
le stack Drupal/LAMP pardonne à peu près tout
sauf l’absence de MàJ.

PASSEZ NOUS DIRE BONJOUR !
Frédéric G. Marand (fgm) Outi Munter (outi)
www.osinet.fr

OSInet
www.osinet.fr
sales@osinet.fr

Recueil des mauvaises pratiques constatées lors de l'audit de sites Drupal 7

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (13)

En vedette

En vedette (20)

Similaire à Recueil des mauvaises pratiques constatées lors de l'audit de sites Drupal 7

Similaire à Recueil des mauvaises pratiques constatées lors de l'audit de sites Drupal 7 (20)

Plus de OSInet

Plus de OSInet (14)

Recueil des mauvaises pratiques constatées lors de l'audit de sites Drupal 7