Suite MAJ WebStation 2.1.3-0139

[DaffY]

Bonjour à tous,

 

juste pour info, la MAJ de version du package WebServer est censée apporter :

1. ajouter une fonction pour configurer le niveau TLS dans les hôtes virtuels.
2. apporter le support de plusieurs profils PHP.
3. corriger des anomalies de configuration.

Perso, j'héberge un petit site wordpress mais par mauvaise habitude... (prise parce qu'à un moment cela ne fonctionnait pas bien en interface IHM du package  avec le couple PHP7 et le serveur NGINX) je paramètre mes fichiers de conf pour nginx manuellement.

Le dossier etc/nginx/sites-enabled permet justement cette possibilité sans que cela ne soit remis en cause avec les différentes mise à jour (enfin jusqu'à présent).

Le point 2 de cette release est la cause de  l'anomalie me concernant : plus d'accès au site, erreur php diverses.

Il y' a bien un changement, dans le sens ou le .sock PHP n'est plus celui qui était appelé jusqu’à présent (je ne sais pourquoi) et son appel est largement différent là aussi... (surement lié  au fameux point 2 de cette release -- plusieurs profils PHP) Je m'en suis rendu compte en jouant avec le paquet et de constater les différences.

Ainsi chez moi j'avais :

Avant

---

 

location ~* \.php$ {
        fastcgi_pass unix:/run/php-fpm/php70-fpm.sock;
        fastcgi_param HOST "[NOMDUSITE].com";
        include fastcgi.conf;
    }

Désormais

---

 

location ~* \.(php[345]?|phtml)$ {
        fastcgi_pass unix:/run/php-fpm/php-15dd2a73-758c-41c1-87d8-69a67c1cf766.sock;
        fastcgi_param HOST "[NOMDUSITE].com";
        include fastcgi.conf;
    }

 

A savoir : le long php-.....69a67c1cf766.sock ne fut créé qu’après utilisation de Webstation en créant un virtualhost supplémentaire (que j'ai supprimé ensuite).

Citation

Voilà si cela peut aider certains et/ou d'autres à apporter du détail sur le sujet.
En tout cas j'ai retrouvé le bon fonctionnement de mon site.

Bon mais je risque d'être bien seul, car il semblerait que la fonctionnalité WebStation fonctionne parfaitement avec NGINX, PHP7 et WORDPRESS...

Heu chez moi non mais en manuel si.

[unPixel]

Bonsoir,

 

Perso, j'ai un soucis avec mon site. J'ai tout simplement une page blanche :(

J’héberge un vieux script php avec bdd pour gérer mes favoris et il ne fonctionne plus. Je ne vois pas trop ce que je peux faire car j'ai qu'une page blanche sans erreur particulière.

[Einsteinium]

Active le display error dans les paramètres de la version php.

Perso j’ai aucun soucis de mon côté, apache 2.4 php 7

[unPixel]

Quand je teste sur autre chose que FF, j'ai pas une page blanche mais ça :

 

Citation

Cette page ne fonctionne pas

Impossible de traiter cette demande via xxx.ndd.fr à l'heure actuelle.

HTTP ERROR 500

J'ai bien activé ce que tu m'as dit mais ça me donne quoi exactement et surtout ou ? Merci à toi

[Einsteinium]

Donc c’est un problème de sous domaine donc, va voir si rien n’a bougé de ce côté là.

[unPixel]

Non car même en testant en normal ça passe pas. ex : ndd.fr/xxx

 

[Einsteinium]

Met directement l’ip locale ^^

[unPixel]

Page blanche aussi avec l'ip locale :(

[Einsteinium]

J’avais pas vue le error 500 en tout petit.

Les permissions sont toujours bonne ? Htaccess si tu as, vire le temporairement pour testé, sinon reste l’erreur dans le script (comme daffy)

[DaffY]

Il s'agit d'un extrait du script de configuration pour nginx.
Perso je n'utilise plus le serveur apache

[unPixel]

Je ne m'y connais pas assez en script php... Mon but était surtout d'héberger mon propre serveur de favoris qui tournait depuis des années sur un free.fr

Il fonctionnait bien jusqu'à la dernière maj de web station...

 

Pour htaccess, je l'ai viré mais toujours pareil.

Pour les permissions, elles sont en lecture sur le dossier du script donc normalement ok.

Reste effectivement peut-être l'erreur dans le script mais là, je ne sais pas.

[Einsteinium]

Script dépassé alors, va falloir que tu mettes les mains dans le cambouis pour l’adapté.

[unPixel]

J'ai surtout l'impression d'un soucis avec apache, ngix ou autre car selon ce que je règle dans webstation, j'ai une page blanche ou des erreurs de script. Pareil pour Wordpress (paquet officiel).

[DaffY]

Avec nginx, plus d'utilisation des .htaccess mais des droits idoines biens disposés : groupe http propriétaire des fichiers en dossier web

[unPixel]

Pour le htaccess en faite, le seul que j'ai est à la racine de web et il me permet d'avoir automatiquement une connexion https sur mon site. Donc si je tape http://xxx.ndd.fr, ça me renvoi automatiquement sur https://xxx.ndd.fr

[Sadi]

Je m’incruste... J'imagine que ce serait l'explication pour laquelle mes scripts ne fonctionnent plus du tout, ce serait à cause de cette mise à jour du WebStation :'( (j'ai la page blanche, page error 505, je ne vais pas m'en sortir :'( )

[unPixel]

Tes scripts sont vieux ? C'est le cas de mon côté.

[Sadi]

Non pas vraiment, les scripts fonctionnent toujours si je tente d'héberger sur un service d'hébergement en ligne (tels que OVH, etc...) mais plus sur nas.

J'imagine qu'il doit y avoir des trucs comme structure / appellations qui a changé avec la nouvelle mise à jour de WebStation non ?

[unPixel]

Il faut que je test mon script avec xamp par exemple pour voir.

[DaffY]

J'imagine qu'il doit y avoir des trucs comme structure / appellations qui a changé avec la nouvelle mise à jour de WebStation non ?

Absolument.

Lors de l'utilisation de webstation cela génère un fichier du genre "webstation.host.conf" dans lequel on constate les lignes d'appel notamment pour PHP.

 

C'est ce dont je me suis inspiré pour produire mon propre fichier de conf que j'ajoute dans le dossier sites-enabled.

 

Bon mais je précise, que je n'utilise pas de serveur Apache mais nginx

[Sadi]

N'étant pas un expert dans la manière, je pense que je vais devoir donc appeler Synology pour un support (même si au fond de moi, j'aurais aimé m'en passer de devoir les appeler)

Mais avant cela j'essaie tout de même à trouver des anciens version WebStations, si t'en as sous les coudes n'hésites pas à m'en partager :)

[Novioritum]

@InfoYANN @Sadi @

Avez-vous créer un profil dans les paramêtres PHP et activer PHP Xdebug. Dernièrement suite à la MàJ de Web Station certains avaient des erreurs et souvent résolu à cause de la connexion à la DB et particulièrement MariaDB10.

Voir ma réponse

 

[unPixel]

Non je n'ai pas fait ça mais en même temps, mon script tournait déjà sous PHP 5 et sous MariaDB 10. C'est pas une mise à jour de MariaDB qui l'a planté mais WebStation.

J'ai pas encore eu le temps de le tester en local pour voir.

[Sadi]

Salut,

Merci @Novioritum, je viens à l'instant de tester la solution proposé, il y a un petit peu du nouveau je crois :)

Alors à présent, ça m'affiche quelque chose plutôt que la page blanche.

Voici ce qu'il affiche :

Fatal error: Uncaught PDOException: could not find driver in /volume1/web/xxxxxxxx/include/data.php on line 7 PDOException: could not find driver in /volume1/web/xxxxxxxx/include/data.php on line 7 Call Stack: 0.0000 360272 1. {main}() /volume1/web/xxxxxxxx/index.php:0 0.0001 360632 2. require('/volume1/web/xxxxxxxx/include/data.php') /volume1/web/xxxxxxxx/index.php:2 0.0001 362032 3. PDO->__construct() /volume1/web/xxxxxxxx/include/data.php:7 

Voici la ligne concerné :

$bdd = new PDO('mysql:host=localhost;dbname=mes_scripts', 'xxx_UTILISATEUR_xxx', 'xxx_MDP_xxx');

Je pense que ça rapproche, quelqu'un comprend quelques choses ? :)

[DaffY]

Bonjour,

 

c'est que j'ai pu constaté (bien qu'en étant avec NGINX) le stack d'appel du PHP est différent AVANT versus APRÈS mise à jour Webstation.
Du coup j'ai réutilisé cette ligne dans mon scrip manuel et les choses se sont résolues.

Pour mémoire : lorsque je paramètre Webstation "tout comme il faut" il me génère un fichier contenant les informaitons pour le serveur nginx, (nottament l'appel PHP qui fonctionne alors) mais cela ne suffit pas pour que cela fonctionne à 100%, donc je m'en inspire et je fais les choses manuellement avec un script déposé dans le dossier sites-enabled.

Citation

A voir si cela peut être fait pour un serveur apache (j'iamgine que oui... ou en jouant sur les fichier htt.access)

 

AVANT :

 fastcgi_pass unix:/run/php-fpm/php70-fpm.sock;

 

APRÈS

fastcgi_pass unix:/run/php-fpm/php-15dd2a73-758c-41c1-87d8-69a67c1cf766.sock;