Update DSM 6 : une mise à jour presque sans encombre

update DSM 6
Ce billet résume les péripéties de cette violente update DSM 6 : les problèmes rencontrés (dans le cadre de WordPress essentiellement) et leurs solutions, pour finalement revenir à un état stable, plus sécurisé et plus performant. Je n'ai aucun doute sur le fait que cette mise à jour à due impacter négativement l'expérience de nombreux utilisateurs de Synology. Tout le monde n'ayant pas un profil très techniques, j'imagine facilement les pétages de plombs 🙂

WTF ! On m'a hacké mon syno !

On le sait tous, mieux vaut toujours utiliser les dernières versions des logiciels, notamment pour des raisons de sécurité. Alors forcément, tout fonctionnant à merveille sur son NAS Synology, on se dit que l'on peut sereinement activer les mises à jour automatiques. Après tout, nous sommes loin de l'époque des dist-upgrade d'une Debian unstable aboutissant sur un kernel panic ! Seulement voila, cette fois ci, c'était plutôt agressif comme mise à jour...

anonymous update DSM 6Le constat au petit matin :

  • un site wordpress avec tous les liens en 404
  • un autre avec que des 403,
  • et sur lequel je ne peux plus me connecter,
  • plus de compte root !

Découvrant fraichement que tout était pété avec l'impossibilité immédiate de faire quoi ce soit sans ce compte root (et sans avoir en tête cette update DSM 6 automatique) j'avoue avoir pendant quelques instants imaginé un hack de toute la plateforme ! Ce premier poste sur stackoverflow témoigne de ce moment de panique ^^'

Rien de bien méchant au final, mais beaucoup de problèmes qui en cachaient d'autres et plusieurs heures à chercher le pourquoi du comment. Ce billet présente les différents cas de figures que j'ai rencontrés avant de finalement tout remettre en ordre.

Update DSM 6

Pour information, cette mise à jour comporte deux volets majeurs :

  • le remplacement de APACHE par NGINX
  • le renforcement de la sécurité avec des changements aux niveaux des droits

Plus d'accès root

La release note annonce :

Donc non, vous ne pouvez plus vous connecter en ssh avec le compte root et ce n'est pas plus mal. Mais ce que ne dit pas cette release note c'est qu'on ne peut plus du tout se connecter au compte root autrement qu'en faisant un sudo !

Pour passer root il faut se connecter avec un compte administrateur et faire un sudo -i.

Problème de droits

Je vous passe les détails de certaines péripéties, mais cette update DSM 6 m'a convaincu d'une chose : plus jamais tu ne toucheras aux droits via le mode console ! En effet, force est de constaté qu'une fois sur deux cela casse les droits gérés simplement par l'IHM, en particulier au niveau du système d'héritage de ces droits.

Après une réinstallation complète de WordPress je peux vous assurer que vous n'avez pas besoin de toucher aux droits des répertoires en mode console. Si cela était vrai avant, avec l'update DSM 6 ça ne l'est plus.

Des pages web en 403

J'ai résolu ce problème uniquement en ré-appliquant les droits depuis l'IHM et en arrêtant de magouiller en mode console lorsque ça ne marchait pas. Imaginons que votre arborescence soit comme ceci : /web/site/wordpress

Alors, dans les propriétés du répertoire "site" mettre par exemple :

  • le owner en admin
  • le groupe http en lecture
  • le groupe users en lecture (nécessaire au moment de la configuration du document root dans l'IHM de gestion de vhost, allez savoir pourquoi)
  • cocher les deux cases à cocher pour que la sous-arborescence dispose des mêmes droits

Ce qu'il faut retenir c'est que le groupe HTTP doit avoir les droits en lecture pour que votre site fonctionne correctement, pour des raisons de sécurité il vaut mieux en revanche ne pas lui donner les droits en écriture, sauf cas particuliers :

  • le dossier upload doit-être accessible en écriture pour le groupe HTTP pour des raisons évidentes
  • d'autres dossiers peuvent avoir la nécessité de laisser le groupe HTTP en écriture, par exemple pour l'écriture de logs dans le cadre du plugins UpDraftPlus.

Configuration des vhosts

Le passage de Apache à Nginx (pour des raisons de performances) cumulé au fait que de nouvelles IHM peuvent maintenant créer les vhosts de façon plus complète qu'auparavant à engendré un beau bordel dans les fichiers de configuration. Certes, les IHM proposent également de continuer de fonctionner avec Apache : cela n'a pas fonctionné pour moi (cela a fonctionné chez d'autres). Par ailleurs, mieux vaut essayer de suivre les recommandations et outils conseillés par cette plateforme et donc tout migrer vers Nginx.

Pour remettre d'aplomb les configurations des vhosts :

  • Supprimer les configurations apache par précaution (backup)

A priori deux fichiers sont concernés :  Apache httpd-vhost.conf-user.3_17_18  et httpd-ssl-vhost.conf-user .

  • Supprimer les vhosts existants dans l'IHM par précaution

En effet, la configuration générée automatiquement par la migration DSM 6 peut potentiellement cacher des problèmes d'accès aux répertoires root de vos sites.

Une fois tous les vhosts normalement supprimés, je me suis aperçu qu'il restait encore des traces : find /usr/syno/etc/www -type f -exec grep thorpora {} + | grep -vi mailserver. Par principe, j'ai préféré supprimer (avec backup tout de même) le fichier trouvé qui n'avait plus lieu d'être : VirtualHost.json.3_17_25. A vous de voir selon votre situation.

  • Choissez Nginx comme serveur HTTP

Si à la reconfiguration du virtual host il est impossible de sélectionner le sous dossier wordpress situé dans /web/votresite, vérifier les droits en lecture pour les utilisateurs.

Voila pour la configuration de base, il reste un point abordé plus loin : les permaliens.

Probleme de timeout avec Nginx

Une fois le site en place et le FTP opérationnel, j'ai constaté des timeouts que je n'avais pas avec Apache : si la mise à jour où l'installation d'une extension par exemple dure plus de 60 secondes, la page s'arrête de charger. Il faut donc faire un check du disque dur et attendre que l'action se finisse véritablement. J'ai tenté de désactiver les timeouts dans Firefox, augmenter tous les timeouts dans les configs Nginx mais rien n'y fait, j'ai toujours ce timeout de 60s.

Ce problème n'a pas (encore) été résolu.

Probleme d'écriture avec le FTP

La encore, c'est simplement un problème de droits. Veillez simplement à bien mettre tout votre site (ou juste les répertoires nécessaires si vous êtes pointilleux) en r/w pour votre utilisateur FTP (pensez bien à cocher les deux cases à cocher dans le fenêtre d'édition des droits d'un répertoire pour l'application des droits aux fichiers enfants).

Une version de WordPress downgradée

MAD update DSM 6Ce problème a très certainement été le pire de tous : disposant d'un site WordPress packagé avec Synology (mais pas forcément en phase du à des restaurations par le passé), l'update DSM 6 m'a downgradé ma version de WordPress entrainant des problèmes de compatibilité dans tous les sens. J'ai donc tenté une restauration via le plugin UpDraftPlus, sauf que cela n'a fait qu'empirer la situation : une fois la base données mise à jour, j'arrive sur le White Screen of the death de WordPress !

Je n'ai heureusement pas eu le problème sur une version de WordPress packagée manuellement.

WordPress et l'écran blanc de la mort

Beaucoup de problèmes peuvent causer ce fameux écran blanc ne nous donnant aucune information. Voici quelques étapes qu'il est conseillé de suivre dans ces circonstances :

  • Passage en debug ( config.php ) : personnellement cela n'a rien donné
  • Renommer votre config.php : si WordPress répond et vous propose une installation c'est bon signe, c'est donc bien un problème de configuration de WordPress et non de la plateforme.
  • Vérifier attentivement le contenu de config.php  (notamment la syntaxe)
  • Supprimer (déplacer) tous les plugins : c'est ce qui à débloqué la situation pour ma part

Au final seul un plugin posait problème, celui ajouté automatiquement par synology : language selector.

J'ai maintenant une page d'accueil !! Mais les problèmes continuent...

No Update Required : Your WordPress database is already up-to-date

Impossible de me logguer sur le site, un mystérieux message s'affichant à la place de la boite de login. Les causes communes sont des problèmes de cache et de base de données corrompue.

Voici quelques solutions (mais pour ma part aucune ne m'a corrigé le problème) :

  • Vérifier s'il n'existe un fichier /wp-content/object-cache.php  et le supprimer le cas échéant.
  • Réparer la BDD via WordPress en mettant WP_ALLOW_REPAIR  à true dans le wp-config.php . Il faut ensuite se rendre sur l'url  http://votresite.com/wp-admin/maint/repair.php  (source)
  • Réparer la BDD via PhpMyAdmin (source)
  • Revenir au thème par défaut, la valeur "default" m'a engendré une page blanche, obligé de mettre le nom exacte du thème :

  • Vider le cache explicitement en exécutant un fichier php (source) :

<?php include( './wp-load.php' ); wp_cache_flush();

OMG update DSM 6Sauf que voila, AUCUNE de ces solutions a fonctionné pour moi, je me suis donc lancé dans une nouvelle installation de wordpress, suivi d'un export/import des données des anciennes tables wordpress une à une avec une attention plus particulière sur la table wp_options.

Ce fut une malheureuse solution mais qui a eu le mérite de me redonner un site pleinement fonctionnel ! Du moins, jusqu'à ce que j'active les permaliens...

Permaliens et Nginx : des pages en 404

C'est en réinstallant un plugin SEO et en activant les noms d'articles comme url (permaliens) que j'ai compris la cause des 404 : la configuration de Nginx ne le permet pas par défaut. L'idée est donc d'ajouter quelques lignes de configuration à nos vhost Nginx. J'ai ouvert un billet sur ce sujet sur stackoverflow, mais j'ai finalement trouvé le bon fichier à base de find et de grep. en fait non, le mieux est de créer des vhosts dans le répertoires site-enabled sans jamais passer par l'IHM comme le présente cet article.

Pour Nginx, assurez vous simplement que les lignes suivantes sont présentes dans vos vhosts wordpress :

Un rechargement de la config Nginx est nécessaire :

nginx -s reload

Pour Apache, il faut créer des .htacess (je ne sais pas le contenu à mettre exactement).

Ceci résout immédiatement tous les problème des 404 liés aux permaliens. Attention si vous régénérez les vhosts depuis l'IHM cela écrasera les modifications ci-dessus qu'il faudra donc refaire. Ouf enfin un site web fonctionnel !! Oops, impossible de connecter Jetpack, problème SSL...

Nginx et la configuration HTTPS

Le problème : le https fonctionne dans le navigateur, mais la connexion sécurisée n'arrive pas à ce faire avec WordPress.com (nécessaire pour le plugin Jetpack) indiquant un problème de certificat non trouvé...

Sans aucune action apparente le problème s'est résolu tout seul après une nouvelle tentative : la connexion à WordPress.com s'est faite et a terminée sur une erreur 502 mais au final JetPack fonctionne bien. Je n'ai toujours pas trouvé la cause de ce problème qui n'est (heureusement) jamais réapparu.

Finalement...

Tout remarche comme avant, avec un grand soulagement : il n'était pas question de hacking mais de l'update DSM 6 ! Ce que je retiens de tout cela, au delà du bienfait formateur, c'est de ne plus utiliser un wordpress packagé avec Synology ! Cela apporte bien plus d'inconvénients que d'avantages. Par ailleurs, merci aux sauvegardes régulières qui m'ont permis de travailler en toute sérénité (enfin, ou presque ;)).

En espérant que ce billet puisse sauver quelques heures de recherche à certains !

HF

14 réponses

  1. trucmuchebidule dit :

    Bonjour et merci pour votre article 🙂
    Je suis tombé exactement sur le même problème… enfin en vrai c’est toujours pas réglé, mise à jour de DSM 6 automatique et downgrade de WordPress puis plus rien. Je me retrouve avec la totalité de mon site avec une erreur 404. Seulement je n’arrive vraiment pas à m’en sortir. Ma base de donnée sur PHPMyAmin est intacte, mon répertoire semble avoir tous les droits suffisants et le plugin multilangue du site (Polylang) semble fonctionner. Par exemple si l’on rentre l’url du site http://192.168.xxx.x/wordpress/ on est redirigé vers la version http://192.168.xxx.x/wordpress/fr/ je ne sais pas si ça a son importance mais ça me donne de l’espoir. Sachant que je n’ai aucune sauvegarde de mon site (je sais c’est pas bien), eh bien j’ai peur de toucher à Nginx. Je me demandais si une solution miracle avait été trouvé depuis (même si j’ai peur que non) pour remettre mon site en état ou alors si il est possible de récupérer une partie de la base de donnée pour la mettre sur un autre site ?

    En tout cas merci à tous ceux qui ont pris le temps de me lire ou de m’apporter un début de réponse 😀

  2. Hello ! Dans de telle situation de crise, même s’il n’y a aucune raison pour que ta base de données soit corrompue, je pense que par principe tu devrais faire un export depuis PhpMyAdmin de toute ta base WordPress. Tu seras plus serein dans les manipulations qui suivront 🙂

    Le fait que ta redirection vers le /fr fonctionne, ce qui est déjà bien lol c’est parce que ce problème de 404 ne concerne pas le répertoire racine, seulement les liens sur articles avec l’option des permaliens activé dans l’IHM WordPress.

    Concernant les 404 :
    – si tu restes sur Apache, il te faudra mettre des .htaccess me semble t’il (discuté avec un autre internaute qui a fait le choix de rester sur Apache)
    – si tu changes pour Nginx ce que je te conseille, tu auras simplement à mettre à jour un fichier comme expliqué dans cet article.
    Ce changement Apache -> Nginx se fait via les IHM (globalement, et pour chaque vhost si tu en as)

    Il est possible que ce soit les uniques actions à faire remettre ton site en état de marche 🙂 Il faut en tout cas commencer comme ça.
    Mais rassure toi, Nginx ne va rien effacer du tout, et même dans le pire scénario (celui évoqué dans cet article en fait), tu pourras toujours t’en sortir à partir du moment ou tu as ta base de données !

    • trucmuchebidule dit :

      Re-Bonjour 🙂

      Désolé de donner des infos si tard, mais n’ayant qu’à moitié réussi à refaire marcher mon site je suis à la limite du désespoir. Enfin en tout cas grâce à ton aide, je peux enfin accéder à ma page d’accueil et la page d’administration est entièrement fonctionnelle (j’ai donc pu faire une sauvegarde du site et des paramètres du thème depuis l’admin, c’est pas tout perdu 😀 ).
      J’ai réalisé le passage à Nginx, désactiver tous les plugins (comme Polylang) remis à jour WordPress, modifier le fichier « server.webstation-vhost.conf » et réparer la base de donnée comme dans ton tuto, mais j’ai dû passer à côté de quelque chose … Puisque j’ai le droit à la page 404 à chaque fois que je clic sur un lien (pourtant les images, l’admin, la première page de l’outil de recherche du site marche). Ça doit être un problème de permalien si j’ai bien compris (je suis un gros noob, excusez-moi pour la question, j’ai un peu honte). J’ai peut être mal réalisé la modification du fichier « /etc/nginx/app.d/server.webstation-vhost.conf » est-il possible d’utiliser une interface graphique pour le modifier ?

      • Malheureusement je ne crois pas qu’il soit possible d’utiliser une quelconque IHM pour l’édition de ce genre de fichiers… Essaie avec vi, même si tu ne connais pas trop tu devrais t’en sortir ! En gros tu n’as pas besoin de connaitre grand chose :
        – en ligne de commande pour ouvrir un fichier : vi ton_fichier
        – une fois dedans, clique sur la touche ‘ESC’ puis ‘i’ pour rentrer dans le mode d’édition
        – ajoute le texte
        – puis quitte : touche ‘ESC’ puis ‘:’ et la tape « wq! » ce qui enregistrera le fichier et quittera l’application
        Forcément quand on ne connait pas vi tout cela peut paraitre un peu bizarre je te l’accorde ^^
        Mais clairement les 404, soit ton vhost est mal fait, soit tu n’as pas rechargé nginx, soit tu as tout bien fait mais Syno a écrasé ton fichier et donc toutes tes modif, d’où la nécessité de faire un backup de ce fichier après chaque modification.

  3. trucmuchebidule dit :

    Super !!! Merci pour votre réponse, donc si y a pas trop de risque, je vais essayer ça au plus vite et je vous dit si ça marche pour mon cas 😀

  4. lericain dit :

    Hello !
    Ca fait quelques jours que je galère depuis la màj DSM également… et là je tombe sur ce post qui m’a pas mal aidé, mais j’ai encore qq soucis.
    D’abord merci de partager cette expérience et les solutions !
    Mon soucis était qu’après la màj en DSM 6, je ne pouvais ni mettre à jour wordpress ou les plugins, ni installer de nouveau plugins.. du coup, j’avais essayé de faire la màj manuel, mais sans succés car je tombais sur la fameuse page blanche de la mort…
    Du coup, j’étais parti pour refaire une install du package wp/synology, mais la lecture de qq posts sur ce blog m’a convaincu de faire une install manuelle et utilisé Nginx.
    A préciser que je possède une copie du repertoire wordpress du syno, et aussi une sauvegarde de la base de données, ça va me servir c’est sûr!
    Donc après avoir suivi les instructions, j’ai d’abord eut une erreur 500, puis après avoir créer le vhost via l’IHM (suis pas allé nettoyer d’autres fichiers, n’ayant pas configuré de vhost précedemment…) j’obtenais l’erreur 404, et en modifiant la config Nginx je retombe sur ma page blanche de la mort…
    A noter que j’ai:
    – copié le repertoire etc/ de ma précédente install dans le dossier wordpress (j’ai essayé avec ou sans, pareil…) ce dossier contient 3 fichiers de config: SYNO.SDS.WordPress.conf, http://www.WordPress.conf et SYNO.SDS.WordPress.ini, je sais pas du tout s’ils sont necessaire…
    – copié le dossier uploads de ma précédente install, mais je pense pas que ce soit important à ce stade…
    – copié mon thème et son thème enfants également
    – modifié le path du repertoire wordpress dans la base de données…
    Là je sèche un peu…
    bon je suis même plus sur si c’est un pb de page blanche ou de 404, car qd je fait https://mon_domaine j’ai une page blanche et si je fait https://mon_domaine/dev/wordpress, là c’est une erreur 404…
    J’ai aussi essayé de me connecté à l’interface d’admin sans succès…
    Toute aide serait bienvenue ! merci d’avance

  5. Salut, merci pour ton commentaire !
    Bon dans toutes ces situations, il y a tellement de causes possibles pour chaque problème, ce n’est pas évident. Ceci dit je retiens que tu souhaites te débarrasser de ce packaging Synology, du coup je te conseillerais ceci :
    – copier tout ton répertoire wordpress syno dans un autre dossier dans /web
    – mettre à jour ton Nginx pour ce nouveau chemin
    – supprimer toute trace de syno dans ton nouveau répertoire, cela concerne les fichiers dont tu parles et le wp-config.php à remettre à jour, tu peux repartir du wp-config-sample.php et y ajouter uniquement les informations de connexion à la base de données (+FTP si tu as)
    – vérifier les droits en lecture du groupe http de ton nouveau répertoire
    – supprimer le ou les plugins installés par synology (par exemple language-selector)
    – retester

    Si tu as encore une page blanche, tente au moins de déplacer tous tes plugins ailleurs et revérifie. Si vraiment c’est toujours ko, c’est peut-être que syno à modifier d’autres fichiers et mieux vaut repartir sur une nouvelle installation propre de WordPress suivi d’un import des données de l’ancienne base, table par table (export ancienne table => suppression dans le fichier exporté des requetes de création de table et index => import dans nouvelle base avec décochage de la vérification des clés étrangères). Cela parait long, ça ne l’est pas tant que ça !

    Lorsque tu parles de modification du path du repertoire wordpress dans la base de données de quoi parles-tu exactement ? Je ne vois pas d’information de ce type stockée en base, et généralement les problèmes ne viennent pas de là donc ne bidouille pas trop les données des tables WordPress 🙂

  6. lericain dit :

    Merci pour ta réponse.
    J’ai relu tout cela attentivement ce matin, supprimer la redirection faite dans le fichier index.php du dossier /web (plus besoin, c’est le vhost qui fait le boulot), refait le wp-config.php comme suggéré et là j’ai obtenu une page 404 systématiquement (aussi bien par https://mon_domaine que par https://mon_domaine/dev/wordpress). A ce stade je suis reparti voir le pb de permalien de gninx que tu avais expliqué dans ton post et me suis rendu compte que la modif n’était plus là.. certainement car j’ai du refaire la config du vhost par l’ihm entre temps…
    ça marche !!! bon c’est lent et pas bien beau, doit y avoir un soucis avec mon theme je vais regarder ça, mais au moins je peux accéder à mon blog !
    Un grand merci pour ton aide !
    Sinon par modif de la base de données, je voulais juste dire changer le chemin des champs siteurl et hote dans la base wp_options.

  7. Ah super ! Content pour toi 🙂 Oui si ta version de WordPress a été downgradée peut-être que ton thème ne marche plus très bien ^^ Sinon par rapport aux urls modifiées dans wp_options, perso les deux pointes sur mon domaine directement (http://thorpora.fr).

  8. lericain dit :

    Bon, après quelques temps passés aujourd »hui, j’ai enfin retrouvé un blog complètement fonctionnel.J’ai passé pas mal de temps à mettre d’équerre ma base de données concernant les url, c’était pas très homogène!
    Merci pour l’info sur les url dans wp_options, en mettant juste le nom de domaine, j’ai résolu mes problèmes de lenteur et aussi de thème !
    Encore un grand merci pour ton aide !

  9. Jim dit :

    Salut,
    Merci pour tes infos, je commençais à me poser des questions. J’ai moins galéré que toi (passage a Nginx et juste correction de droits), mais sans ton aide j’aurai cherché encore un bail.

  10. ashtonerreck dit :

    Bonjour,

    Et merci pour cette article qui m’a été utile pour les permaliens. Même si j’attends quand même de la part de Syno une stabilisation de la situation avec une vrai utilisation de l’IHM qui est censé être là pour ça.

    En parallèle à ce problème WebStation/Wordpress, je suis confronté à un autre que je n’arrive décidément pas à résoudre depuis la MAJ en DSM 6 :
    – J’utilise PhotoStation en y accédant notamment depuis l’extérieur avec mon nom de domaine ****.synology.me
    – Depuis la maj 6.0 je n’y accède plus par le nom de domaine mais j’y arrive par mon @IP/photo

    Il me semble qu’à l’époque j’avais configuré cet accès (sur un port dédié) par le reverse proxy accessible dans Paramètres > Portail des Applications > Proxy Inversé

    Je sèche un peu là. Je pense qu’il y a encore une histoire de configuration du serveur Web.

    Auriez-vous une idée ou avez-vous eu le même problème ?

    Encore merci

  1. 5 avril 2016

    […] l’expérience m’a convaincu de ne plus utiliser la version packagée de WordPress ! Ce billet vous donnera un aperçu de divers problèmes que j’ai rencontrés […]

  2. 5 avril 2016

    […] est plus performant et surtout moins gourmand en mémoire. Si vous choisissez Nginx vous aurez à mettre à jour le fichier de config des vhosts manuellement pour faire fonctionner les permaliens. Si vous choisissez Apache, il vous faudra ajouter des […]

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *