Modification des variables php.ini

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

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 ???

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 ?

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 !

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.

Ok je vais tester ça, merci :)

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.ovhcloud.com/community/fr/transfert-de-site-d-un-mutu-vers-un-cloud-web?id=community_question&sys_id=a9d1310081928210f0780f07683eb214

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...

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.ovhcloud.com/community/fr/activer-memcached-pecl?id=community_question&sys_id=aca5b988359a82d0f078b41a47e1f0a0

pour le remboursement, Ovh ne connait pas:
https://community.ovhcloud.com/community/fr/support-client-1007?id=community_question&sys_id=46217944fd5e8e902d4c483e6acd51d1
https://community.ovhcloud.com/community/fr/mysqldump-sur-cloudweb?id=community_question&sys_id=fb3079c0b51a0ad0f078da7e5576c9de

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é...

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?

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)

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)

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"

Sur un cloud web ?

Oui messire

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 ^^

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éé

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 !

Fais juste attention à faire tourner une cron pour tar.gz tes logs, ya pas bcp d'espace disque sur cette offre.

oui merci :)

mon phpinfo est sur un cloudWeb
il est clairement indiqué que le user_dir n'est pas pris en charge....

à l'inverse d'autres hébergeurs où j'ai cette fonctionnalité

il semblerait que certains, au moins sur un pro, ont cette possibilité configurée

https://community.ovhcloud.com/community/fr/variable-upload-max-filesize-plus-grande-que-post-max-size?id=community_question&sys_id=55a139c09d1e4e901e11a21128f2cf79