Kioob

Sous Plesk, pas de manière automatique à ma connaissance. Mais il y a peut-être moyen de modifier le "umask" du serveur FTP (il me semble que Plesk installe un ProFTPd), afin de le mettre à 000 et ainsi avoir tous les dossiers en 777 et les fichiers en 666. Mais à ce niveau, autant installer un Windows.

Hello, une manière simple de faire cela serait d'utiliser PHP 5 en ligne de commande. Un coup de SimpleXML et c'est réglé en quelques lignes.

Ce qu'il faut bien voir c'est que tu as une installation de type Plesk, donc quoi que tu fasses tu seras toujours limité à ce que propose Plesk... et justement à ma connaissance Plesk ne gère qu'un seul type d'installation Apache/PHP. Pour les autres schémas qui te font tellement envie, il faut repartir sur un OS "propre", quitte à déléguer l'installation/infogérance à Dan par exemple. En attendant, il te faudra bien faire avec les contraintes de l'installation actuelle... en essayant d'en comprendre le fonctionnement. Faire du chmod ou chown à droite et à gauche sans savoir pourquoi, c'est risqué. Par exemple si le "chown" indiqué par rdd fonctionne (si tu ne te trompes pas dans la syntaxe quoi), il y aura fort à parier que tu perdras ton accès FTP, en écriture du moins... le "access denied" ne sera plus pour tes scripts PHP mais pour ton accès FTP, quel est le mieux ?

Il s'agit là d'une sécurité UNIX, donc soit tu fais la modif depuis le compte root soit tu le fais par FTP, mais tu n'aurais guère plus de solutions. Ca n'a absolument aucun rapport. mkdir(), unlink(), fopen() et toutes les fonctions de manipulation de fichiers fonctionnent parfaitement en safe_mode, y compris avec open_basedir actif. Si tu veux conserver un minimum de sécurité, il faut que l'utilisateur exécutant les scripts soit différent de l'utilisateur propriétaire des scripts... et ça, peu importe le modèle choisi (mod_php, fastcgi+suexec, ou suphp). Après tu peux évidement t'assoir sur l'aspect sécurité et faire sauter ça... Comme la plupart des hébergeurs mutualisés d'assez grosse taille, ils sont certainement en FastCGI + suExec, ce qui est généralement plus sécurisé que le "mod_php" classique. Parce que tu ne cherches pas à comprendre pourquoi ça ne marche pas ?

Bonsoir, alors en gros : - le swap est normalement utilisé en cas de manque de mémoire ; mais c'est tellement lent que généralement ça n'arrange pas vraiment les choses : ça va ralentir le système, donc souvent augmenter le nombre de processus Apache simultanés et ainsi consommer encore plus de mémoire. Bref, quand un serveur swap, c'est souvent mauvais signe (dans ton cas 220K c'est rien). - le load average, tout le monde n'a pas vraiment l'air d'accord sur ce point. De mon point de vue, idéalement le load average ne devrait pas dépasser le nombre de vrais processeurs (en divisant par deux en cas d'hyperthreading quoi). Pour un core2duo, la limite serait donc de 2. Mais ce n'est qu'un indicateur, certains processus influent fortement sur le load average sans pour autant gêner le système. De ce qu'on peut voir par contre : - tu as des processus (dont MySQL) qui bouffe beaucoup de CPU. Il faut peut-être tenter d'optimiser la configuration de MySQL et/ou les traitements SQL. - tu as deux processus "zombies", dont au moins 1 PHP, user "meetarab". Je ne sais pas si ça te parle, mais visiblement certains traitements ne se déroulent pas comme prévu...

Quand il s'agit d'une restriction du safe_mode ou bien d'open_basedir c'est généralement clairement indiqué dans le message d'erreur. Là il s'agit vraiment d'erreurs "unix" classiques : pour pouvoir faire un chmod sur un fichier (ou dossier), il faut soit être root (ce qui n'est pas le cas là, ton PHP tournant sous le compte apache) soit être propriétaire du fichier en question. Si c'est un fichier uploadé par FTP le propriétaire n'est pas Apache non plus ; chmod ne sera utilisable que sur les fichiers créés via PHP. Quant à mkdir il faut avoir les droits d'écriture dans le dossier supérieur pour pouvoir y créer un dossier. Bref, je ne suis pas certain de savoir ce que tu cherchais à faire, mais pour ton chmod à priori c'est à toi de le faire manuellement via FTP, ce qui te permettra ensuite de faire le mkdir via PHP. Et ré-active le safe_mode et l'open_basedir, tu as retiré la seule protection des environnement configurés via Plesk

Question bête : où as tu vu que le chmod() et le mkdir() étaient bloqués à cause du safe_mode ? Il faudrait les lire les messages d'erreur en entier, mais tu ne nous en as mis que le début... Du coup ça pourrait être un "simple" problème de droits unix, et non une restriction du safe_mode ou de l'open_basedir.

En passant, petit inconvénient des Dedibox : il n'y a pas d'IP flottante. L'option IP supplémentaire attribue une IP "fixe", elle pointera toujours sur la même machine, dixit le support. Du coup pour de la redondance, OVH marque un sérieux point là.

La doc officielle à ce sujet : http://dev.mysql.com/doc/refman/5.0/fr/subqueries.html Et non, MySQL (phpmyadmin n'a rien à voir là dedans) ne placera jamais tout seul les données dans l'ordre que tu voudrais.

Dans ce cas je pense que le plus simple est d'utiliser une requête imbriquée, ou autre mécanisme du genre. Une première pour obtenir les 10 "plus basses", puis la jointure pour obtenir les infos "détaillées".

L'ordre d'écriture sur le disque n'a heureusement aucune signification. Si aucune clause "order by" n'est précisée, il faut considérer que les "lignes" sortent dans un ordre "alléatoire".

Faire un "GROUP BY strict_name" alors que le strict_name est fixe, c'est balo quand même. Enlève le GROUP BY, ça devrait mieux fonctionner déjà... Après pour avoir juste une ligne, deux solutions : - faire un SELECT MIN(n_data) : le plus efficace à mon sens, mais ne permet de récupérer qu'un seul champ (ou presque) - ajouter un ORDER BY n_data DESC LIMIT 0, 1

Je ne connais que très peu Plesk, donc ça ne va pas être évident. Le plus sage serait certainement de créer un autre sujet, avec un titre adéquat. Donc pour le premier point, en passant purement par Plesk (sans bricolage donc), non je ne sais pas faire. Pour le deuxième point c'est "normal" : dans un environnement de production il est fortement déconseillé d'afficher les erreurs (d'où le display_errors qui est à off pour les sites sous Plesk). Je me souvient plus à quel niveau Plesk modifie ça, mais de mon coté je créais simplement un fichier .htaccess dans les dossiers où j'avais besoin de l'erreur et j'y plaçais un php_flag display_errors on. Sinon il me semble qu'il y a moyen de modifier le "template" utilisé par Plesk pour la configuration des virtual hosts, mais pour le coup il faudra certainement demander sur un forum spécialisé Plesk.

Yep, c'est ce que je vois. Ils sont très forts chez 1and1 quand même

De rien De mon coté ce que retourne maintenant tes serveurs DNS semble tout bon. Mais avec un délai de mise à jour de 24 heures, il va effectivement falloir patienter un peu

Apache fonctionne : le port est ouvert, et certaines pages répondent : http://82.165.86.97/ Sinon via la bonne URL j'arrive à voir la page d'accueil de temps en temps, mais c'est extrêmement lent. La plupart du temps on a un joli timeout en fait. Edit : mea culpa, maintenant Apache est effectivement down (port fermé). Ca a l'air méchamment en carafe chez eux.

Vire une des IP (à priori 213.165.94.152) parmis ces lignes pour les deux domaines ; ça supprimera le "round robin" et tout le monde devrait ensuite voir la même chose (moyennant la mise à jour du cache DNS évidement) : Pour l'inversion de NS, ça ne concerne que le "warning" de Zonecheck comme quoi les noms ne correspondent pas. Il s'agit de ces deux lignes : A remplacer par : Par contre les 2 IP pointaient vers la même machine, donc coté configuration Apache/Plesk en fait les domaines étaient associés à une seule IP, ce qui peut aussi être modifié si tu tiens à ta deuxième IP. Cette deuxième IP n'est nécessaire que pour pouvoir créer le ns2.jld-hebergement.com ; et ainsi tromper le zonechek de l'AFNIC.

re, je ne sais pas comment tu t'es débrouillé dans ta configuration DNS, mais tu as un joli "round robin" sur ton domaine. Les deux serveurs DNS répondent la même chose, à savoir que le domaine pointe tour à tour (de manière "alléatoire" donc) sur les IP 87.106.217.160 et 213.165.94.152 ; ce qui correspond également aux IP des serveurs DNS. Petit extrait d'une réponse de l'utilitaire dig : ;; ANSWER SECTION: bannieres-en-ligne.fr. 86400 IN A 87.106.217.160 bannieres-en-ligne.fr. 86400 IN A 213.165.94.152 ;; AUTHORITY SECTION: bannieres-en-ligne.fr. 86400 IN NS ns1.jld-hebergement.com. bannieres-en-ligne.fr. 86400 IN NS ns2.jld-hebergement.com. ;; ADDITIONAL SECTION: ns1.jld-hebergement.com. 86400 IN A 87.106.217.160 ns2.jld-hebergement.com. 86400 IN A 213.165.94.152 Bref, à priori tu as confondu les différents champs dans ta configuration DNS. Ton site est sensé être sur quelle IP en fait ? edit: sinon oui je confirme que tu as inversé ns1 et ns2 dans tes déclarations. Ton serveur DNS retourne : Alors que le proprio des IP indique :

Si le problème est présent aussi sur d'autres PC, c'est qu'il s'agit d'un soucis coté configuration DNS, comme par exemple les deux serveurs DNS du domaine n'ayant pas la même configuration (bien que cela fasse partie des tests du ZoneCheck normalement). Quel est le domaine qu'on puisse vérifier ?

Hello, il y a un truc particulier sur les mutus OVH pour envoyer les mails ? Si ce n'est pas le cas, n'importe quel code habituel fonctionnera... et il vaut mieux utiliser une librairie "toute prête", de type PHPMailer, html_mime_mail, ou encore SwiftMailer.

Ma première réponse était bonne... tu as juste à corriger ton "setcookie" qui est faux.

1 Byte (anglais) = 1 Octet (français) = 8 bits (anglais et français)

les modifications dans $_COOKIE ne sont pas envoyées au navigateur.

Justement elle est supérieure : 2000Go pour 1and1 US contre 1000Go pour 1and1 France. Et il s'agit de 1and1... Je suis persuadé que les hébergeurs spécialisés dans le dédié aux US font beaucoup mieux. Quand à un ordre d'idée, et bien ça ne veut absolument rien dire : cela dépend énormément de la "consommation" par visiteur. Dans mon cas c'était un site de fonds d'écran, donc poids des images à prendre en compte. Mais en contre partie les pages étaient compressées et le cache du navigateur assez bien exploité. Le tout avec 5 à 6'000 visiteurs uniques journaliers, à l'époque. Mais je "gère" aussi un site qui ne dépasse pas le 1Mbps de consommation avec 40'000 visiteurs uniques journaliers... et un site proposant quelques videos ou mp3 peut faire exploser ça avec 1'000 vu/jour... bref, ça dépend vraiment des sites. Tu n'as aucune stats pour ton site actuel ?

Le "1000GB" indiqué n'est pas plus précis, c'est juste qu'il s'agit de la vraie limitation qu'ils appliquent. Le 100Mbps n'est là qu'à des fins commerciales, pour "tromper" le client. Quand OVH, Sivit, et bien d'autres affichent 20, 40 ou 100Mbps, il n'y a pas de sous entendu, c'est la "vraie" limite (bien que cette bande passante ne soit pas garantie). Et non, 1000GB c'est ridicule selon le contenu du site... je bouffais déjà 400Go par mois quand j'étais en mutualisé il y a 5 ans...