ozmonitor

Bonjour, Merci pour votre intérêt. Effectivement le download time est plus important généralement. Mais ... on doit avoir "un peu" de lookup, connect et response time. Si ces trois derniers ne sont pas visibles sur le graphe (quelques ms), c'est que le downloadtime dépasse la seconde ! Il faut lire également les valeurs listées au dessous du graphe donnant le current, le max et l'average. Pour bien comprendre le fonctionnement de la supervision de votre site, je vous conseille de comparer vos perfs avec ceux de Google, Yahoo et MSN ::: Voir : La Demo Cordialement,

Bonjour, Merci pour votre intérêt. Bien évidemment, vous avez la possibilité d'utiliser libremment ozMOnitor. Cependant vous n'avez pas le droit de vendre les rapports ou les services ozMonitor. La fourniture des rapports et des alrétes produites par ozMonitor devront rester gratuites vis-à-vis de vos clients égalements. Cordialement, ozMonitorien

Bonjour, En effet, Cacti est beaucoup plus simple, mais ... il consomme un peu :-( Attention a l'utilisation du snmp sur un serveur dédié accessible sur le Net ! A mon avis, n'utilisez que les scripts internes "simples" avec mrtg, cacti ou ... cricket ... Cordialement,

En effet, mais Google est source de plus de 80% des nouveaux visiteursr (selon mes stats d'usage de nos sites web)

Bonjour, En effet, le forum n'est pas assez clair. Mais ... un peut de .... En ce qui concerne le référencement, avez-vous utilisé Google Sitemap ? Bon courage.

Bonjour, Il faut distinguer la supervision interne et externe. Certes Nagios/Oreon est un bon produit mais il reste assez compliqué à comprendre et .. à mettre en place. Pour votre information OVH propose un "petit" package pour MRTG : mrtg-sys. Il permet de superviser les éléments standard du serveur avec l'outil basic/standard MRTG. En suite il y a la supervision externe du site web depuis une plate-forme externe afin de donner la vision internaute (en terme de dispo et de perf) du site web en question. Il ne faut pas oublier la sauvegarde ! (avec rsync/ssh par exemple) Bon courage.

Bonjour, Pour simplifier le réferencement de vos pages utilisez Google sitemap ! Bon courage.

Bonjour, Un CMS comme joomla par exemple est une bonne solution. Cependant, pour une association un Blog comme DotClear peut répondre à ce besoin. Bon courage.

Effectivement. Mais ... ce type de language me rappelle windev ou encore webdev ! Je prefère attendre un peu avant de passer à RoR.

Bonsoir, Incroyable mais vrai ! Pensez-vous que Ruby va détrôner PHP ?

Bonjour, D'abord, je vous conseille d'utiliser la librairie class.phpmailer. Mais ... si vous voulez utiliser la fonction mail alors ... 1/ Faites un message de debug du type echo "mail($recipient, \"Formulaire de contact\" ,$msg, \"From: $email\r\nReply-To: $email\")"; 2/ Ensuite, si l'affichage est correcte, vérifier que votre serveur est capable d'envoyer un email : echo "mon test de mail" | mail -s "mail de test" email_AT_serveur.com 3/ Et enfin, faites un test avec la fonction mail simple (comme un hello word) Bon courage.

Bonjour, D'abord, mettez le chemin complet de votre commande dans le script en question par exemple /usr/local/bin/hcitool ...... Ensuite, si dans le scripte vous contrôlez les timeouts ... alors, ... Bon courage.

Pour la barre de scrolling, cela dépond de votre système d'exploitation, enfin je pense. En ce qui concerne le texte, aucune idée. Mais en tout cas, il va falloir mettre dans ta feuille de style la directive suivante : direction: rtl Exemple : div { direction: rtl }

Certes, mais c'est fortement utile dans le cas où le AuthUserFile est un fichier du type .txt (n'est pas caché). Utile aussi dans le cas où, on rencontre un bug ==> on ne met pas tous les oeufs dans le même panier !

En théorie, mais ... vaut mieux ne pas facilité la vie aux hackers en mettant tous les oeufs dans le même panier !

Non, le serveur web ne partage (sauf bug ou trou de sécurité) que la directory web (htdocs par défaut avec apache) donc pas le système complet (sinon il partagerait aussi le /etc/password !) Il faut mettre le .htpasswd hors le protocole http c-a-d hors le htdocs.

Il vaut mieux installer ssh, car faire cela en telnet/rexec est encore plus risqué !!!

Attention, il faut mettre seulement le .htaccess dans la directory htdocs Et .... le .htpasswd ailleurs (dans les /home ou les /etc par exemple) On met seulement le chemain du .htpasswd dans le .htacess. Come cela, on est protégé

Effectivement, c'est très risqué. Mais si vous insistez, la solution est la suivante : 1/ création d'un jeu de clef privé/public (entre les deux serveurs) 2/ mise en place d'un script sur le serveur distant 3/ mettre ceci dans la page php exec ou system (ssh toto_AT_serveur_distant /opt/script.sh); Bon courage.

La migration entre un site de dev et un autre de prod n'est jamais une chose facile. Cependant, on applique tjs la même recette : - Avant la migration, il faut faire un backup des datas, scripts et bdd - Désactiver le site ==> "Site en Maintennace" - Mise en place du nouveau système (nouveau site, scripts, bdd, data ...). Pour la copie, il y a rsync, rcp ..., mais moi, je préfère le bon "tar czf" suivi d'un sftp (sécure ftp), puis ... ssh En ce qui concerne votre problème avec la BDD, il faut faire une sauvegarde via les outils de la BDD (mysqldump pour MySQL par exemple) Bon courage.

Effectivement, le meilleur moyen de proteger un répertoire est .htaccess Avec le javascript le contenu est dèjà livré par le serveur web ! alors ... pas de protection :-( ==> .htaccess simple et efficace :-)

Désolé, les rapports personnalisés ne traitent que les pub adsenses pour les pages de contenu ! Il va falloir attendre les conversions !

Je n'ai pas testé cette fonctionnalité non plus, mais il me semble bien qu'on a la possibilité de créer des rapports personnalisés avec Google Adsense. J'ai le même pb que toi p/r au parrainage FirefoxByGoogle. Je pense que la solution consiste en l'activation de ces rapports. je vais en activer/créer un maintenant et on verra :-) Bon courage

Que donne Les rapports archivés ?

Bonsoir, Pour les ORT, voir le lien suivant : http://guides.ovh.com/RedirectionsGratuites/contenu.html Mais ..., en effet, après relecture du post, je pense que la réponse de glibre est la bonne. Il est plus simple de gérer les vhosts, en plus, vous pouvez mettre les logs de chaques vhost dans un fichier indépendant, histoire d'analyser les stats par client. Bon courage.