Modification des variables php.ini

[BenjaminP2]

Bonjour,

Je viens de souscrire à l'offre cloudweb... j'ai une question toute simple : comment peut-on modifier le php.ini ? J'ai cherché partout en SSH mais je ne trouve rien... ou au moins un moyen d'afficher les erreurs PHP ?
Idem pour relancer apache ? Je ne trouve aucune commande en SSH :/
Ca manque un peu de documentation tout de même !!

Merci par avance pour le coup de main
Benjamin

[kyodev]

tu es sur un mutualisé
sur Ovh tu n'a pas la main sur tout cela avec un mutualisé

pour les logs j'ai pas fait attention

[BenjaminP2]

Ok on ne peut pas modifier sa conf PHP... ce qui n'est pas très cohérent avec la description commerciale de l'offre : "La liberté de configuration d’un serveur isolé, la rapidité d’un disque SSD, la simplicité d’un hébergement managé." mais bref.
Par contre, il y a forcément un moyen d'afficher les erreurs PHP non ? Ca me parait tout de même indispensable sur une offre d'hébergement quelle qu'elle soit ???

[Boulvard]

Pour le php.ini tu peux créer un .user.ini qui te permettra de modifier les variables de ton phpinfo.

Après pour relancer apache, je vois pas trop l'utilité vu que tu as pas la main sur les vhosts. Tu penses à des cas particuliers ?

[BenjaminP2]

Bonjour, merci pour votre réponse.
concernant le fichier .user.ini, il faut que je le dépose à la racine du site ? la syntaxe est la même que le php.ini ?
Concernant la question sur la relance d'apache c'était simplement pour que les modifs de la config de PHP soit prise en compte, au cas où j'aurais pu modifier le php.ini !

[Boulvard]

De mémoire c'est à mettre dans ton httpdoc (le répertoire où ya ton site) et oui c'est la meme syntaxe.

De mémoire (encore) tu n'as pas besoin de relaunch apache pour appliquer tes modifs.

[BenjaminP2]

Ok je vais tester ça, merci :)

[kyodev]

cloudWeb, cluster24:

version php clairement pas à jour, 05/2018 !

version en cours 7.2.14, avec nombreux fix de sécurité

pas de .user.ini

si vous avez confiance aux discours marketing d'Ovh, vous allez pas être déçu:
https://community.ovh.com/t/transfert-de-site-dun-mutu-vers-un-cloud-web/12806/27

[BenjaminP2]

Bonjour, oui je viens de tester le fichier .user.ini n'est pas pris en compte (c'eut été trop beau)
Du coup je viens de prendre 1 an de cloud web pour rien.
Je me demande si un VPS Cloud ne pourrait pas mieux répondre à mes besoins ? Je voudrais la liberté d'un dédié sans les risque de pannes matérielles en fait...

[kyodev]

Vps n'est pas forcément source de fiabilité, c'est quelque part du mutualisé aussi, si l'hôte est un rade ou l'infra Ovh (j'en connait qui ont attendu 38heures)...

c'est à toi de maîtriser le système Linux, ne te fais pas endormir par un clicOdrome que l'on peut chercher à te fourguer

https://community.ovh.com/t/activer-memcached-pecl/13017/3

pour le remboursement, Ovh ne connait pas:
https://community.ovh.com/t/support-client-1007/13591/3
https://community.ovh.com/t/mysqldump-sur-cloudweb/13726/8

[BenjaminP2]

Merci pour ta réponse Kyodev.

En fait je maîtrise déjà linux, j'ai déjà plusieurs serveurs dédiés avec des debian nues que j'infogère tout seul.
Le soucis c'est que je suis tributaire d'une panne matérielle, par exemple un disque dur qui pète...
J'ai déjà eut le cas plusieurs fois, et à chaque fois j'ai eut plus vite fait de recommander un serveur, de tout réinstaller et de migrer mes data plutôt que d'attendre une éventuelle réparation de la part des tech OVH.

Là je dois mettre en ligne le site d'un client qui génère plusieurs milliers d'€ de CA par jour et je ne peux pas me permettre de le laisser en rade plusieurs jours.
Donc, ma logique est la suivante : Le VPS Cloud est virtualisé, donc beaucoup moins de probabilité de panne matérielle que sur une machine isolée non ? Et je conserve une totale liberté au niveau de la config vu que je peux prendre le VPS avec une distrib nue ?

Mais bon, je n'ai pas de recul sur ces offres n'ayant jamais testé...

[kyodev]

alors dédié ou Vps oui
mais pour les deux, tout repose sur la fiabilité du support ici...
je me contente des lectures du forum ou des dépannages que je fais rarement ici.

en cas de soucis, il est plus rapide de remonter un autre système sur un autre serveur que d'attendre l'intervention du support
pour le disque, normalement tu devrais avoir un raid?

[BenjaminP2]

Oui un Raid soft... Sauf qu'à chaque fois que j'ai eu une panne le changement de disque a pris tellement de temps (+ la reconstruction du raid) que dans la panique j'ai migré...
Le problème des dédiés c'est que le matériel vieillit et forcément au bout de quelques années on a des problèmes (j'ai déjà eut une panne de carte mère, une panne de carte raid quand il y avait encore le raid hard)

[kyodev]

oui
le tout est de présumer quelle est la période avant qu'un dédié subisse une panne matérielle
(je n'ai pas d'opinion bien franche)

[Boulvard]

Tu m'étonnes pour le .user.ini, je vérifie dès que j'ai un creux mais suis sur et certains que c'était fonctionnel

Ba non je confirme j'arrive bien à changer la variable local =
date.timezone = "US/Central"

[BenjaminP2]

Sur un cloud web ?

[Boulvard]

Oui messire

[BenjaminP2]

Effectivement sur cette variable ca fonctionne, j'avais du faire une fausse manip tout à l'h...
Je vais donc essayer d'activer les logs PHP de cette manière ! merci ^^

[Boulvard]

Si ça peut t'aider je pense que ça doit ressembler à ça :

display_errors=On
log_errors=On
error_log = "/home/tonuserftp/logs"

Avec un dossier logs de créé

[BenjaminP2]

Yes, j'ai ajouté ça :

error_reporting = E_ALL & ~(E_STRICT | E_NOTICE | E_USER_NOTICE | E_WARNING | E_DEPRECATED | E_USER_DEPRECATED)
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /home/xxxx/www/php-errors.log
log_errors_max_len = 0
max_execution_time = 600;
max_input_time = 600;

Ca fonctionne nikel... Bon bah du coup désolé pour le bruit et merci Boulvard !