OVH Community, votre nouvel espace communautaire.

AWStats en multi domaine (offre PLAN)


Daniel60
17/04/2015, 16h26
Et hop !
http://demo.ovh.eu/fr/6522d704615bb37586fbefb40a98c345/ valable 30 jours.
A garder précieusement pour répondre au prochain demandeur... je ne peux rester éternellement le seul gardien du temple

Spider31
17/04/2015, 12h12
Bonjour,

Je déterre un peu ce sujet, quelqu'un aurait-il une copie des fichiers anciennement situés aux urls ci-dessous et qui ne fonctionnent plus ?

ftp://ftp2.lolart.net/lolart/awstats_config.zip
http://demo.ovh.eu/fr/89d2cbf86e1094cac5c9afe3df178102/

Merci d'avance pour votre aide.

padpad
18/01/2015, 14h59
Merci de nouveau. c'est exactement ça (scripts) que je ne savais pas faire.

Daniel60
18/01/2015, 14h19
Je peux te fournir mes scripts : http://demo.ovh.eu/fr/89d2cbf86e1094cac5c9afe3df178102/
Pour la config de Awstats tu pourras lire la doc.

padpad
18/01/2015, 12h26
un souci idiot ..
Sur le howto, les fichiers de config sont proposés à l'adresse ftp://ftp2.lolart.net/lolart/awstats_config.zip
oui mais .. l'adresse en question a disparu .

QQn aurait une copie de ces fichiers ?
Merci

padpad
17/01/2015, 23h19
merci beaucoup

Daniel60
17/01/2015, 19h52
J'utilise toujours cette configuration qui me donne pleine satisfaction. Je ne pense pas que ce soit différent avec une offre pro actuelle.
L'idée du wget est intéressante pour avoir une actualisation de la journée en cours, mais ceci est déjà proposé par OVH.
Sinon la récupération des logs en http fonctionne très bien.
Le seul soucis que j'ai rencontré provenait de pannes cron, et là il faut être vigilant car Awstats ne sait pas revenir en arrière, et s'il y a un trou, il faut tout effacer et tout rejouer depuis le début du mois.

padpad
17/01/2015, 17h26
Bonsoir
Je découvre ce fil fort intéressant mais qui n'a pas bougé depuis qq années.
Sur une offre pro, aujourd'hui, si on veut se faire des stats simplement ( mais sur période ad-hoc), l'état de l'art est-il toujours
1) d'installer AWSTATS
2) de récupérer les logs par des séries de Wget
3) de les renvoyer à l'analyse ?

j'utilisais un produit local et acheté, advanced log analyser, mais il n'a pas supporté une migration

merci de vos lumières

Daniel60
28/07/2011, 17h48
I M P O R T A N T
----------------
Bonjour,

Ayant upgradé en version 7.0, je tiens à signaler que les droits du nouveau fichier awstats.pl (16.10.2010) doivent être passés à 755.
Faute de quoi on obtient une erreur 500.

yades
21/03/2011, 12h01
Citation Envoyé par ALeX!S
Bon, un petit coup de main car je vois que beaucoup font de la récupération de logs à la main (j'y pense même pas).

Je viens de reprendre en quelques minutes à peine, 200Mo de logs.

J'utilise la commande wget disponible sous linux, et téléchargeable ici pour les windowsiens. (Copiez l'exe dans x:\WINDOWS\system32, afin de l'utiliser ou vous voulez, quand vous voulez).

Ensuite, créez vous un répertoire de travail ( ex: x:\logs-ovh\ )

Puis vous faite "démarrer" - "Exécuter" - "cmd". Vous voilà en invite de commande dos.
Vous vous rendez dans votre répertoire ( cd x:\logs-ovh\ )

La il ne reste plus qu'a utiliser ce truc un peu barbare (mais tellement efficace)

Code:
wget -r -l1 --no-parent -A *.log.gz http://NICKHANDLE-OVH:password@logs.ovh.net/domaine.tld/logs-MM-YYYY/
Vous y mettez chaque fois le mois et l'année, ensuite enter. Il suffit d'utiliser "flèche haut" pour rappeler la commande.. On incrémente le mois de 1, et hop !!!

Il suffit de quelques minutes (ça dépend de votre vitesse de connexion) pour récupérer tout les logs disponible chez OVH.

Reste que vous êtes la avec des logs.gz, pas cool….

Si vous avez WinRAR, vous pouvez sélectionner tout les fichiers du répertoire (CTRL+A) et faire « Extraire ici », il ne reste plus qu'à uploader le tout (les .log - vous pouvez virer les gz, qui sont déjà selectionné), et traiter les fichiers...

Bon amusement.
J'ai du modifier le code pour que ça marche

Code:
wget -r -l1 --no-check-certificate --no-parent -A *.log.gz https://NICKHANDLE-OVH:password@logs.ovh.net/domaine.tld/logs-MM-YYYY/
Yades

kitten13
08/10/2010, 14h17
Effectivement j'y suis presque, me reste plus cas gérer les dates (ranger par "mois" dans un dossier ) puis écrire les logs dans 1 fichier/jours ... etc ... par contre je sais si c'est utilise de compresser les logs ...

Daniel60
08/10/2010, 14h11
Dans ce cas tu devra respecter un dessin d'enregistrement compatible AWStats et le renseigner dans la config.
Bon courage !

kitten13
08/10/2010, 10h21
Le but est d'utiliser les logs créer via php sans avoir a récupérer ceux générer via apache qui sont dans un répertoire protéger (cron, tranfert/copie), afin d'obtenir des logs frais quand ont le souhaite.

Dans mon cas j'ai juste à mettre mon code dans l'include appeler dans toute les pages de mon site.

pour ce qui est des outils en ligne tel que analystics, Xiti et compagnie j'aime pas trop ses outils pour des raisons X, je préfère donc étudier les logs brut via un outils comme AWStats qui semble parfaitement me convenir.

Je suis en train de modifier le petit bout de code afin d'écrire les logs, j'en suis ici:
Code:
$fp = @fopen("track.log","a");
$now = '['.date("d/M/Y:H:i:s O").']'; 
$string = $_SERVER['REMOTE_ADDR'] . " " . $_SERVER['HTTP_HOST'] . " - " . $now . ' "'. $_SERVER['REQUEST_METHOD'] . $_SERVER['QUERY_STRING'] . ' ' . $_SERVER['SERVER_PROTOCOL'] . "\n";
@fwrite($fp,$string);
@fclose($fp);

Daniel60
08/10/2010, 10h15
Excuses-moi, mais je n'ai rien compris à la manœuvre
Tu te proposes d'écrire un fichier log en concurence avec celui d'OVH ?
Quelle est la tâche qui va venir écrire dans ton fichier ?
Un script sur chacune des pages du site ?
Autant utiliser un utilitaire bien connu tel Xiti ou autre

kitten13
08/10/2010, 09h47
Bonjour Gaston_Phone,

Oui c'était juste une idée brute mais effectivement c'est plus conventionnelle.

Sinon l'idée de réécrire des log semble bon ? Cela évite toutes les autres manipe, etc...

Par contre je me demande si il faut les compresser obligatoirement ...

Aussi éviter de loger les accès au image, css, etc .. afin de pas alourdir les log et écrire un fichier log par jour, bref ....

Gaston_Phone
08/10/2010, 09h44
On peut aussi écrire plus simplement :
Remplacer :
Code PHP:
$today getdate();
$now $today['year'] . "/" $today['mon'] . "/" $today['mday'] . " " $today['hours'] . ":" $today['minutes'] . ":" $today['seconds']; 
Par :
Code PHP:
$now date ("Y/m/d H:i:s"); 

kitten13
08/10/2010, 09h37
Bonjour danield60,

Afin d'éviter d'avoir à lancer un cron ou galérer pour récupérer les logs, pourquoi ne pas en créer via php un peu comme ceci:


$fp = @fopen("fichier.log","a");
$today = getdate();
$now = $today['year'] . "/" . $today['mon'] . "/" . $today['mday'] . " " . $today['hours'] . ":" . $today['minutes'] . ":" . $today['seconds'];
$string = "ip:" . $_SERVER['REMOTE_ADDR'] . " -ref:" . $_SERVER['HTTP_REFERER'] . " -agent:" . $_SERVER['HTTP_USER_AGENT'] . " - " . $now . "\n";
@fwrite($fp,$string);
@fclose($fp);
?>
Ainsi ont à toujours les derniers log à jour ... C'est juste une idée mais en créer un log dans le format identique générer par apache ...

kitten13
07/10/2010, 16h43
Est-ce suffisament clair
Simple, clair et précis ... Merci

Daniel60
07/10/2010, 16h41
Parce que les logs se situent dans un répertoire contrôlé par OVH auquel tu ne peux pas accéder autrement que par une transaction OVH.
Cette transaction n'autorise pas directement le traitement de ces fichiers par le script Perl d'AWStats situé dans ton répertoire.
Est-ce suffisament clair ?

kitten13
07/10/2010, 12h41
Bonjour,

Ce que je comprends pas, c'est pourquoi il faut récupérer les logs pour les copier dans un autre répertoire ...

- Est il possible d'utiliser directement les logs sans avoir à les copier/transférer ?

Daniel60
16/05/2010, 12h07
La procédure décrite fonctionne chez moi depuis plus de quatre ans.
Si vous ne vous donnez pas la peine de réfléchir un brin, comme je ne suis pas au dessus de votre épaule pour regarder ce que vous faites (ou ne faites pas) je ne peux qu'avancer des hypothèses. On peut appeler ça des devinettes si vous voulez .
Vérifiez votre script (en l'occurrence copie_log_local.php5) en ajoutant en tête l'instruction "error_reporting(E_ALL)", vos mots de passe (attention il s'agit de ceux du nic-handle et non ceux du ftp), vos répertoires, etc.
Après votre succès, vous pourrez alors revenir ici pour écrire une procédure "rénovée" .

K3nsh1n
16/05/2010, 10h48
Surement que le tuto n'est plus à jour.... Si je connaissais la réponse je ne viendrais pas demander. Est-il possible d'avoir une aide concrète plutôt que des devinettes ?

Daniel60
10/05/2010, 22h12
0 octets... Awstats va avoir du mal a bâtir ses stats avec ça !
Donc le problème se situe au niveau de la récupération des logs apache.
Et ça vous fait penser à quoi ?

K3nsh1n
10/05/2010, 19h29
Le fichier pèse 0 octets :S

Daniel60
09/05/2010, 21h09
Toujours aussi peu précis : 0 visiteur, bien sûr, ça veut simplement dire que ça ne fonctionne pas, mais à quelle étape ?
Par exemple quelle est la taille du fichier ~/www/stats/apachelogs.log s'il existe ?

K3nsh1n
09/05/2010, 09h38
Comme indiqué dans mon message un peu plus haut, j'ai suivi tout le tuto (je me suis arrêté avant de configurer l'exécution automatique des script), j'ai suivi les étapes correctement, mais lorsque je me rend sur la page des stats, cela m'indique 0 visiteur.

Daniel60
08/05/2010, 10h59
Exprimez clairement les étapes votre démarche, et les problèmes rencontrés, car "ça ne fonctionne pas" ne permet pas d'établir un diagnostique.

K3nsh1n
08/05/2010, 10h35
Personne pour me renseigner ?

K3nsh1n
05/05/2010, 22h47
Merci pour ce tuto.

Je viens de tenter de le faire (je dis bien tenter, à chaque fois que j'essaie de toute façon ça ne fonctionne pas... ). Lorsque le suis sur ma page Awstats, les stats m'indiquent 0 visiteurs (alors que j'en ai lorsque je regarde via https://logs.ovh.net/....

Ou est le probleme ?

Nickx
11/02/2010, 15h46
c'est bon j'ai trouver comment j'ai pu le savoir.
J'ai tout simplement creer un fichier "e.txt" en "e.php" avec sa dedans :







Puis j'ai été sur www.monsite.fr/e.php

la il m'a indiquer une phrase avec une erreur et le homeXX etait ecrit

probleme résolu tout fonction, reste plus qu'a demander a ovh pour les cron

merci tuto super

Nickx
11/02/2010, 15h25
merci pour la réponse.
Je viens d'aller dans le manager mais je ne vois pas ou je peux trouver le répertoire "/home" ou autre que je pourrai avoir ?

Je ne savais pas que le dossiers cgi-bin était protégé, mais copie_log_local.php5 est quand meme dans le dossiers /stats avec un aspirateur de site on pourrai surement le prendre et voir le login et mot de passe non ?

Daniel60
11/02/2010, 14h16
1- Le répertoire /home n'est peut-être pas valable dans ton cas, il peut s'agir d'un /homez.NN . A vérifier dans le manager.
2- Les login et mot de passe sont situés dans le répertoire protégé cgi-bin

Nickx
11/02/2010, 10h34
bonjour,

tout d'abord merci pour se tuto.
J'ai suivi tout a la lettre mais j'ai cependant quelque problème. Quand je veux mettre à jour mes stats il me dit sa.

Error: Couldn't open server log file "/home/pcactivi/www/stats/apachelogs.log" : No such file or directory

Setup ('./awstats.www.pcactivity.eu.conf' file, web server or permissions) may be wrong.
Check config file, permissions and AWStats documentation (in 'docs' directory).

J'ai pourtant vérifier tout mais je ne sais pas ou sa coince. Mon fichier apachelogs.log est bien remplis avec les stats donc c'est que le reste c'est bien passé.

Autre question, point de vus sécurité cela ne pose pas de problème, y a un fichier ou il y a notre login et mot de passe dedans...

Si quelqu'un pouvais m'éclairer.

Merci

Daniel60
17/05/2009, 20h23
Il faut comprendre que tout ce système est basé sur les logs bruts fournis par Apache.
En fonctionnement normal, ceux-ci sont alimentés en temps presque réel - environ toutes les 10 minutes - puis la journée complète est archivée vers 3 heures du matin.
S'il y a des interruptions de service dans l'archivage ou dans le suivi en temps réel - cela arrive parfois - il peut y avoir effectivement des soucis. Cela est contrôlable sur logs.ovh.net

Une autre source d'ennui pourrai être lié à la tâche cron, mais dans ce cas il est prévu dans le script qu'un mail vous soit adressé.

Awstats fait de stats à partir de ce qu'on lui donne, il peut donc aussi le faire en temps semi-réel, ce n'est pas le problème.

Par contre, comme je vous l'ai déjà dit, la mécanique décrite dans ce HOW-TO fonctionne à J-1, et ne peut être garantie pour un autre usage.

allatoja
17/05/2009, 16h29
Bonjour!
Pour Daniel: le problème est que ça a marché trois jours, puis ça s'est arrêté de fonctionner trois jours, puis ça a remarché encore trois jours, et depuis 4-5 jours plus rien. Si j'avais raté quelque chose dans le tuto, cela ne marcherait pas du tout, il me semble...
Quant aux stats en temps réel: je ne comprends pas pourquoi Awstats n'arrive pas faire ce que peuvent faire d'autres scripts beaucoup plus simples. Et je n'ai pas trouvé de réponse ici. Dommage!

supernova34
15/05/2009, 10h00
Non mais mais c'est la mort, AWStats....OVH...La marque blanche...
J'ai réussi à faire la jour mise à jour une fois d'AWStats, après j'ai zappé.
Maintenant t'as des super stats avec google analytics, c'est gratos.
Sinon tu as https://logs.ovh.net/tesdomaines avec OVH en background et big n'importe quoi !
Désolé je me lâche, lace, funky OVH///
C'est vraiment dommage qu'il ne fasse pas plus d'effort sur ses soit disant mutu pro. (avec un petit m et un petit p).

Bonne journée anyway !

Pfuff !

Nice to see you,

see ya,

jim

Daniel60
15/05/2009, 09h16
Allons, n'exagérons pas : ce système fonctionne depuis un an à la perfection.
Si vous avez bien suivi le tuto et s'il n'y a pas de problème au niveau OVH, ça doit tourner.
Une remarque : comme votre question précédente concernait la récupération des stats du jour courant, il est possible que cela entraine des difficultés, la mécanique étant prévue pour fonctionner J-1.
Quand aux stats basées sur des scripts... C'est vous qui voyez !

allatoja
15/05/2009, 09h03
...Bon, eh bien non, cela ne va pas: ça marche un jour sur deux ou un jour sur trois, allez savoir pourquoi...
Il est bien sympa cet outil de statistiques, mais s'il faut un mois à un informaticien de métier pour l'installer, il y a un petit problème. Je crois que je vais me tourner vers phpstats, qui fait la même chose et qui s'installe en cinq minutes.
Bonne journée

Daniel60
05/05/2009, 18h19
De rien

allatoja
05/05/2009, 18h13
...Bon, eh bien j'ai enfin compris: enlever "mktime(-1)", et ça marche! Merci pour votre aide!
Bonne journée

allatoja
04/05/2009, 14h27
Eh bien, j'ai enlevé mktime, comme vous me le disiez...(voir message #262)
C'est sûrement idiot de ma part, je le sais!

Daniel60
04/05/2009, 14h22
C'est quoi ce ,(0) ?

allatoja
04/05/2009, 13h01
Bonjour Daniel, et merci de votre réponse,
J'ai fait ce que vous me dites, cela donne:

$log = strftime($domaine_ovh."-%d-%m-%Y.log",(0)); // Nom du log de la veille (mktime(-1) pour le jour précédent)
$replog = strftime("logs-%m-%Y",(0)); // Répertoire du mois en cours
$reposl = "osl";

Là, j'ai un beau message d'erreur par mail...j'ai sûrement loupé quelque chose, mais quoi?

Daniel60
04/05/2009, 11h17
J'ai remplacé (mktime(-1) par (mktime(0), sans résultat...
Ne pas mettre mktime

allatoja
04/05/2009, 10h39
...j'ai oublié de dire que j'avais trouvé ça dans le fichier copie_logs-local.php5:

$log = strftime($domaine_ovh."-%d-%m-%Y.log",mktime(-1)); // Nom du log de la veille (mktime(-1) pour le jour précédent)
$replog = strftime("logs-%m-%Y",mktime(-1)); // Répertoire du mois en cours
$reposl = "osl";

J'ai remplacé (mktime(-1) par (mktime(0), sans résultat...
Des idées? Merci d'avance!

allatoja
03/05/2009, 23h33
Bonsoir, je viens de suivre pas à pas le tutoriel de la première page. Cela marche très bien, merci à l'auteur!
Une question cependant, comment faire pour que les statistiques comprennent la journée en cours? Car chez moi elles s'arrêtent à J-1...

Daniel60
20/04/2009, 11h14
A priori, oui. Cependant les répertoires contenant les logs ne sont certainement pas les mêmes.

Wolverine
20/04/2009, 11h04
Bonjour à tous.

J'aimerai installer awstat sur un serveur dédié RPS.
Est ce que la méthode indiqué ici est tout aussi valable ?

Merci pour votre aide.

Daniel60
20/12/2008, 13h36
Vous avez donc "splitté" le fichier du site principal avant traitement. C'est un peu brutal !
Lorsqu'on ne veut pas de stat pour un site il suffit de ne pas faire de fichier .conf pour celui-ci, c'est tout.

nectar
20/12/2008, 11h06
Citation Envoyé par Daniel60
Il faut bien sûr un fichier awstats.www.siteN.com.conf par site.
Avec les bons paramètres !
C'est bien ce que j'ai fait pourtant... J'ai finalement contourné le problème en faisant 1 fichier apachelogs.log par site. En plus, je n'ai pas besoin de stats sur tous les sites, donc comme ca, je n'ai pas des logs inutiles qui encombrent mon espace.


A+

Daniel60
19/12/2008, 20h19
Sur mon 90plan cela fonctionne parfaitement.
Il faut bien sûr un fichier awstats.www.siteN.com.conf par site.
[edit]
Avec les bons paramètres !

nectar
19/12/2008, 15h09
Bonjour à tous,

Super ce HOWTO ! Je viens d'installer AWstats sur mon 240plan. Pour le moment, j'ai 3 sites différents pour lesquels je souhaite des stats séparés.
Mais j'ai un petit problème : Pour accèder aux stats, je vais à l'adresse suivante :
Site1 : http://www.mondomaine.com/cgi-bin/aw...=www.site1.com
Site2 : http://www.mondomaine.com/cgi-bin/aw...=www.site2.com
Site3 : http://www.mondomaine.com/cgi-bin/aw...=www.site3.com

Mon problème est qu'à chaque fois, j'obtiens exactement les mêmes stats (on dirait qu'on les stats de tous les sites à chaque fois).

Auriez vous une idée du problème ?

Merci !

gorgonite
07/08/2008, 11h32
Bonjour à tous,
j'aimerais utiliser les stats awstats en rappatriant mes fichiers de logs sur une machine centrale et ce pour plusieurs sites. Jusque là, le tuto me convient parfaitement.

En revanche, et j'ai vu que la question avait été posée, mais était restée sans reponse, j'aimerais pouvoir consulter les stats d'un seul jour et non pas les stats mensuelles (pour le tableau avec les IP qui accèdent au site par exemple).

J'avais pensé à faire un rebuild des stats globales en n'ajoutant que le fichier de log du jour concerné et en ayant au préalable supprimé les fichiers awstats*.txt du site concerné.
Pourriez vous me dire si cette solution est viable ? J'ai vu qu'il semblait y avoir des soucis au niveau du cache de ce qu'AWStats garde après une compilation...

Tous avis ou conseil seront les bienvenus

Merci et bonne journée à tous.

Daniel60
23/04/2008, 16h26
Il y a apparemment un problème de mémoire... trop d'éléments à traiter ?
Quelle est la taille du fichier ?
La solution consiste peut-être à abandonner la partie tri du script (les logs sont bien ordonnés actuellement).

ehud69
23/04/2008, 12h16
Bonjour à tous;

J'utilise ce HOW TO génial depuis le mois d'octobre 2007

Seuleemnt depuis quelques mois, j'ai un problème particulier : les stats fonctionne pendant 3 jours puis plus rien pendant 4 jours

En mars c'était aléatoire
De etemps en temps j'ai ce message danbs le planificateur de tâches :
X-Powered-By: PHP/5.2.5
Content-type: text/html

<br />
<b>Fatal error</b>: Allowed memory size of 33554432 bytes exhausted (tried to allocate 343060 bytes) in <b>/home.10.17/cvamm/www/stats/copie_log_local.php5</b> on line <b>51</b><br />

Si quelqu'un a une idée, ce serait super sympa
Ehud

christian38
28/11/2007, 17h06
Cela fonctionne maintenant avec mon login ftp et le chmob 755 sur awstats.pl que j'avais oublié.

Merci beaucoup

J'ai lancé via le "Planificateur de tâches" du manager V3, l'execution des fichiers copie_log_local.php5 et update_awstats.sh.
On va voir...demain

A + et encore merci.

Christian

Daniel60
28/11/2007, 16h08
1 -LogFile = " /home/login/www/stats/apachelogs.log "
login peut être effectivement le nom du site, mais ce n'est pas obligé car réduit à 8 caractères. Ce login est le même que celui du FTP.
2 -cd /home/login/cgi-bin/awstats
même réponse. Il n'y a pas lieu de remplacer home
Mais je crois que le script devrait être dans cgi-bin

christian38
28/11/2007, 15h24
Bonjour,

J'essaie de faire du multi-domaine.
J'ai suivis ce howto depuis le début et quelques problèmes subsistent :
J'ai utilisé AWStats v 6.7

La copie de log fonctionne. C'est sur la mise à jour et l'accès à awstats que cela ne fonctionne pas...
Symptôme :
Quand je vais à : http://www.mon_url.fr/cgi-bin/awstat...e_concerné.org
Le serveur me renvoi :
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator, tech@ovh.net and inform them of the time the error occurred, and anything you might have done that may have caused the error.


More information about this error may be available in the server error log

J'ai un doute sur la configuration des fichiers suivants :

1 - awstats.url_de_mon_site.fr.conf :

LogFile="/home/url_de_mon_site_sans_extention/www/stats/apachelogs.log"

Que mettre à la place de home ?
Url_de_mon_site ? Si l'url est "monsite.com" faut-il bien mettre "mon_site" sans l'extention ? Ce qui donne /home/mon_site/www/stats/apachelogs.log

2 - update_awstats.sh :

cd /home/login/cgi-bin/awstats
Que mettre à la place de home ?
Que mettre en login ? url de mon domaine principal, Nic Handle ovh...?

Merci de m'éclairer
Christian

zlooj
29/10/2007, 15h07
Désolé de faire upper le post, mais j'ai toujours un "Stats OVH non exécutées, erreur dans le script..." quand je fais la copie manuelle.

Est ce que ça peut etre du aux travaux OVH en cours qui annoncent des ralentissements sur les logs ?

zlooj
24/10/2007, 10h07
J'ai retenté ce matin : toujours pas d'erreur 500, mais un mail au postmaster : "Stats OVH non exécutées, erreur dans le script..."
Le script est-il buggé ?

Abogil, je ne comprend pas ce que tu m'as écrit, peux tu donner un peu de précision au newbie que je suis stp!
Je n'ai pas installer ce script. Si il faut le faire, comment faire ?
J'ai déjà testé la copie manuelle, qui ne fonctionne pas.

Citation Envoyé par Abogil
Pour que copie_log_local.php5 fonctionne, il faut que tu sois dans le dossier où tu a installé ce script :
Code PHP:
   // Une fois par jour minimum :

  // Copie des logs

   
chdir("Dossier");
   
$URL "copie_log_local.php5";
   if (
is_file($URL))   include_once($URL);  

  
// Mise à jour des stats (depuis n'importe quel dossier)

   
$URL "http://www.tondomaine.com/cgi-bin/awstats.pl?framename=mainright&update=1";
   if (
is_file($URL))   include_once($URL); 

zlooj
23/10/2007, 09h27
Merci Abogil de ta réponse.

J'ai installé effetivement la derniere version de Awstats (la 6.7 donc).
Désolé, je ne vois pas de quel script tu parles. J'ai suivi le HowTo et tout marche mis à part la copie manuelle.
Je n'ai donc pas fait la partie en copie automatique. Est-ce ça ?
Bon je vais essayer de comprendre ce script que tu m'as laissé, merci.

Ce matin le script à fonctionné (pas d'error 500) j'ai bien reçu un mail sur le 'postmaster' mais il dit :
Stats OVH non exécutées, erreur dans le script...
Des idées ?
Des idées ?

Abogil
23/10/2007, 05h59
As-tu été voir http://awstats.sourceforge.net/ ?

Puis download awstats-6.7.zip

Pour que copie_log_local.php5 fonctionne, il faut que tu sois dans le dossier où tu a installé ce script :
Code PHP:
   // Une fois par jour minimum :

  // Copie des logs

   
chdir("Dossier");
   
$URL "copie_log_local.php5";
   if (
is_file($URL))   include_once($URL);  

  
// Mise à jour des stats (depuis n'importe quel dossier)

   
$URL "http://www.tondomaine.com/cgi-bin/awstats.pl?framename=mainright&update=1";
   if (
is_file($URL))   include_once($URL); 

zlooj
22/10/2007, 22h34
Bonjour,

Merci pour ce tuto fort bien fait !
Malheureusement, j'ai un chti souci, les stats pas mise à jour lors de l'install (c'est à dire manuellement via le fichier copie_log_local.php5).
Tout le reste marche, mais quand je lance: http://www.monsiteprincipal.tdl/stat...log_local.php5 j'ai une error 500.
Quelqu'un a une idée ?
Du coup j'ai mes stats sur les différents noms de domaine, mais vides...

Merci

speps
27/06/2007, 14h20
Salut,

J'ai fait le HOWTO, mais j'ai quelques problèmes.

Tout d'abord, j'ai demandé au support OVH pourquoi je ne pouvais pas accéder aux logs depuis SSH et on m'a répondu que l'accès au réseau était impossible depuis les serveurs SSH. Il faut donc passer par un script PHP en http pour récupérer les logs, je n'ai d'ailleurs pas trouvé comment lancer un script Bash depuis cgi-bin (500 Internal Server Error quand j'essaye).

Ensuite, j'ai pu tout de même récupérer les logs en local sur mon disque et les inclure dans AWStats. J'ai fait pour cela un script Bash qui télécharge et décompresse les logs depuis un certain nombre de jours puis j'ai utilisé le script "logresolvemerge.pl" pour les fusionner. Je peux fournir le script Bash si quelqu'un en a besoin, cela fait pareil que les scripts config_log_local.php5 et config_log_local_full.php5.

Maintenant que j'ai les logs, depuis le début de mon hébergement, dans AWStats, j'ai voulu consulter les stats domaine par domaine (j'ai fait 2 awstats.(.*).conf) mais les stats se retrouvent mélangées. Avez-vous une idée de comment faire pour que j'aie les stats séparées ? Merci.

speps.

Raoul_s
16/06/2007, 10h35
Est ce qu'une bonne âme pourrait m'expliquer comment utiliser le script update_awstats.sh à l'aide de webcron.org svp ?

Merci.

Marty
13/06/2007, 12h42
Bonjour,

Je me permets de remonter ce post car j'essaie d'installer Awstats et j'ai un peu de mal. Premièrement, lorsque je clique sur "Mise à jour Immédiate" j'ai ceci :

No qualified records found in log (0 corrupted, 0 dropped)

D'autres part, le copie_log_local.php5 ne fonctionne pas pour moi, il m'affiche une page blanche. En revanche le copie_log_local_full.php5, lui fonctionne bien, mais lorsque je le lance j'ai ceci :

Fichier ac***c.fr-14-05-2007.log non trouvé !

Et ça vaut pour toute la durée que je souhaite récupérer.

Quelqu'un peut m'aider ?

Raoul_s
06/06/2007, 12h26
Bon ça ne marche jamais chez ovh, ça a marché quelque temps et plus rien depuis le 22, j'en ai un peu marre.
Est ce que quelqu'un pourrais faire un petit tuto récapitulatif sur comment passer par webcron, pour les gens comme moi qui ne maitrisent pas tres bien ? Que changer dans les script, etc.

Ça serait super. Merci d'avance.

Raoul_s
05/06/2007, 10h12
Pareil pour moi... depuis le 22 mai.

Daniel60
05/06/2007, 07h57
Le cron OVH n'a pas tourné ce matin

Abogil
25/05/2007, 07h30
phpjobscheduler
Sur ce post, regarde page 3 ma réponse #94.

Pacmanito
25/05/2007, 07h28
il y a webcron.org, mais ça ne marche pas toujours

Raoul_s
25/05/2007, 01h25
Moi après 1 mois de problemes et de longues correspondances avec la hotline (par email) ça a finalement marché pendant 2 mois et depuis le 22 ça ne remarche plus.

Je vois plus trop quoi faire.
Y-a-t-il une autre solution pour lancer les cron que de passer par Ovh ?

gr4821-ovh
23/05/2007, 23h50
Bonjour,

J'ai demandé a OVH de mettre en place les taches cron indiqué pour la mise à jour des stats.

Pour le fichier copie_log_local.php5 ça marche sans problème.

Par contre pour le update_awstats.sh
ça marche pas.... j'ai demandé de mettre ça comme tache:

05 3 * * * /home.10.15/xxxxxx/cgi-bin/update_awstats.sh

et voila le message d'erreur :

Test de la commande: /home.10.15/xxxxxxx/cgi-bin/update_awstats.sh :
##### OUTPUT #####
-su: /home.10.15/xxxxxxx/cgi-bin/update_awstats.sh: /bin/bash^M: bad interpreter: Aucun fichier ou r�ertoire de ce type
##### END OUTPUT #####


Dans mon fichier update_awstats.sh j'ai ça :

#!/bin/bash
# A mettre dans le dossier cgi-bin
# Remplacer le /home/login par les valeurs correspondant à votre compte
cd /home.10.15/xxxxx/cgi-bin/awstats
perl awstats_updateall.pl now



j'ai essayé d'enlever awstats car mon fichier se trouve dans cgi-bin/ mais ça donne la même erreur..


Le CHMOD est ok pour tous les fichiers.


Est ce que quelqu'un aurait une idée de pourquoi ça marche pas...?

Merci

rafael

Abogil
11/05/2007, 09h33
Sur mon 90plan, j'ai récupéré les stats correctement via copie_log_local.php5 tous les jours depuis le début du moi de mai.

Les dernières coupures datent de :
12 Avr 2007 0 0 0 0
16 Avr 2007 0 0 0 0
17 Avr 2007 0 0 0 0
18 Avr 2007 0 0 0 0
19 Avr 2007 0 0 0 0
20 Avr 2007 0 0 0 0

Pacmanito
11/05/2007, 09h33
vous avez de la chance, elle n'ont jamais marché pour moi les tâches CRON, (Ovh dit le contraire !)

ALDOO
11/05/2007, 09h25
Pour moi
J'ai eu une interruption des tâches cron le 7,8 et le 9
( pour la page copie_log_local.php5 )


Merci pour vos reponces.

Daniel60
09/05/2007, 12h56
J'ai eu une interruption des tâches cron du 5 au 7 (voir plus haut #225).
Le support n'a pas pas répondu, mais c'est revenu à la normale.

Abogil
09/05/2007, 12h09
Sur mon 90plan, la page copie_log_local.php5 a fonctionné correctement 2 fois ce matin. J'ai bien récupéré les stats du mardi 8 mai.

ALDOO
09/05/2007, 11h34
Bonjour,

Grâce à toutes ces explications j'ai installé avec succès Awstats

Tout fonctionnait bien...

Et depuis deux jours

La page copie_log_local.php5(exécuté par une tache cron)

Ne récupère plus les logs

Et envoie une erreur...

Est-ce que quelqu'un d'autre rencontre ce même problème?

Et d'où pourrait venir le problème?

Alors que tout fonctionnait très bien.

Je vous remercie d'avance

Cordialement

Daniel60
05/05/2007, 08h09
Bonjour,
La tâche cron d'OVH n'a pas tourné pour moi ce matin. Avez-vous ce problème ?

Raoul_s
03/05/2007, 09h50
Ok donc après presque 30 jours de réglages divers, mon problème venait juste d'OVH et des crontabs.
Maintenant tout est reglé.

jimbob
30/04/2007, 16h11
Bonjour

Je suis désolé, mais je n’arrive pas a configurer correctement awstats.

J’ai un plan720 et une vingtaine de multi-domaines. J’ai créé 3 fichiers awstats.www.toto.com.conf, awstats.www.titi.com.conf et awstats.www.domainprincipale.com.conf.

Ils sont tous identiques sauf pour les deux zones SiteDomain et HostAliases qui suivre le format du nom de fichier.

Néanmoins, ils donnent tous les mêmes résultats pour pages visités etc.

Est-ce que quelqu’un peut m’aider s’il vous plaît ?

Merci en avance,
James

Raoul_s
13/04/2007, 10h10
Ça ne marche toujours pas chez moi, les problemes sont changeants, un jour ça marche, un jour non, le script copie_log_local.php marche en manuel mais pas par le cron, etc...
Ce matin ce script ne marche plus non plus en manuel, alors que je n'ai rien changé.

Je ne sais plus quoi faire.

Pacmanito
02/04/2007, 14h50
Le support à répondu. Ca marche soi-disant.
mes fesses ouais !

michaeljack
02/04/2007, 12h48
J'ai opté perso pour Xiti, rapide et efficace....

Raoul_s
02/04/2007, 11h38
Oui che zmoi non plus ça ne marche plus.

Pacmanito
02/04/2007, 11h08
pareil ! mais ça fait depuis + longtemps.
J'ai envoyé une première demande au support qui m'a répondu que ça marchait !
pas de réponse depuis 4 jours au sujet de la 2eme demande.

Mox20
02/04/2007, 11h02
Le CRON ne marche plus chez ovh ? Pars que ça maintenant deux jours que le fichier copie_log_local.php5et update_awstats.sh ne s’exécute plus automatiquement, je suis obligé de faire manuellement.

Raoul_s
30/03/2007, 10h08
Merci, par contre c'est normal que je le reçoicve 60+ fois (cette nuit aussi) ?

Daniel60
29/03/2007, 14h50
A priori il suffit de commenter cette ligne
Code PHP:
//  @mail("postmaster@".$domaine_ovh,"[ OK ] CRON Stats-OVH --> OK","Stats OVH OK exécutées correctement"); // Envoi d'un mail de confirmation 
Il suffit de garder le message "Stats OVH non exécutées" c'est bien suffisant

Raoul_s
29/03/2007, 10h21
Donc chez moi tout remarch, enfin presque.
Cette nuit j'ai reçu 61 emails de confirmation du cron. De 3h à 4h, toutes les minutes.

Avant ça j'ai eu ce message :
Test de la commande: /home/xxxx/cgi-bin/update_awstats.sh :
##### OUTPUT #####
/home/xxxx/cgi-bin/update_awstats.sh: line 3: cd: /home.10.5/xxxx/cgi-bin/awstats: Aucun fichier ou r?ertoire de ce type
Can't open perl script "awstats_updateall.pl": Aucun fichier ou r?ertoire de ce type
J'ai donc remplacé la ligne /home.10.5/xxxx/cgi-bin/awstats par /home.10.5/xxxx/cgi-bin/
vu que j'ai mis tout les script au premier niveau de mon dossier cgi-bin.

Donc Quel est le probleme et comment faire pour ne pas recevoir d'email de confirmation a chaques fois ? (et surtout 61).

Merci.

Pacmanito
27/03/2007, 08h57
vu merci.
Le passage en cron du script, lui ne marche toujours pas. Et le support ne répond pas depuis vendredi. Wait and see !

Abogil
26/03/2007, 11h01
Actuellement, il y quelques dérangements temporaires de copie_log_local.php5. Voir mon post : Awstats - copie_log_local.php5 encore en panne

Pacmanito
26/03/2007, 08h47
depuis que j'ai donné le script à mettre ds la crontable, le 1er jour : ça n'a pas marché et depuis le 2eme jour, plus aucun des scripts copie_log_local.php et copie_log_local_full.php ne marche. Ca mouline puis je reçois l'erreur [ ERREUR ] CRON Stats-OVH. Je met donc pour l'instant mon fichier apachelogs.log à jour manuellement.
Il va falloir que je renvoie un petit mail

funkyphenix
23/03/2007, 09h27
Bonjour à tous.

Tout d'abord, merci pour ce super script. J'ai mis un peu de temps à comprendre l'ensemble des éléments à paramétrer mais au final, ça marche... !

Ma question concerne un petit point de détail.
Les services d'OVH ont ajouté le script copie_log_local.php5 à la crontable et je reçois bien tous les jours à l'heure demandée le mail de confirmation (envoyé par le script).

Seulement ce qui est curieux, c'est que je reçois 6 à 8 exemplaire du même mail. Est ce que quelqu'un est dans le même cas ? Si oui, d'où peut provenir le problème.
La seule explication que j'ai trouvé c'est qu'OVh exécuterait sa commande de lancement du script 7 fois de trop.... mais ça me semble improbable.

Si quelqu'un a une piste... merci de me tenir au courant.

brunon
23/03/2007, 01h20
Merci Daniel60 de vous être attardé sur mon cas
mais vous avez dû louper mon message ci-dessus disant que ça marchait à nouveau.
Merci quand même

Daniel60
18/03/2007, 09h15
Citation Envoyé par brunon
je lance le script avec webcron
Avez-vous testé en http ou ssh ?
Citation:
Posté par Daniel60
Alors pourquoi ne pas télécharger directement le fichier en local ?
c'est possible ?
Oui, mais c'est un par un

Citation Envoyé par brunon
Le script copie_log_local.php5 me copie mes logs dans un répertoire et je les récupère une fois par mois.
Ok. Alors ce n'est pas le script original.

Si vous êtes sûr de votre script alors pourquoi ne pas le signaler à Gilles ici

Ah, j'oubliai : essayez aussi avec l'extension .php simple

brunon
18/03/2007, 02h31
Citation Envoyé par Daniel60
Comment le lancez-vous ?
je lance le script avec webcron
Citation Envoyé par Daniel60
Alors pourquoi ne pas télécharger directement le fichier en local ?
c'est possible ?

Le script copie_log_local.php5 me copie mes logs dans un répertoire et je les récupère une fois par mois.

Et comme j'ai 2 sites sur mon hébergement, j'ai écrit un script en php qui me sépare les logs des deux sites dans deux fichiers séparés, que j'exécute en local.
Je peux ensuite analyser mes stats pour mes sites respectifs

Daniel60
17/03/2007, 18h00
Citation Envoyé par brunon
le script copie_log_local.php5 ne s'effectue pas correctement.
Comment le lancez-vous ?
En fait je n'utilise que le script copie_log_local.php5 pour récupérer les fichiers logs (qu'il faisait très bien avant) que j'analyse par la suite en local sur un analyseur de stats.
Alors pourquoi ne pas télécharger directement le fichier en local ?
Quand vous parlez de modifier les chemins dans le script, vous parlez de quels chemins exactement ?
Ceci est valable en cas de traitement ultérieur par awstats sur site.

brunon
17/03/2007, 14h51
Citation Envoyé par Daniel60
Normalement les scripts du lien du #1 sont à jour(sauf https ?).
merci pour votre réponse

Ca marche maintenant

brunon
17/03/2007, 14h49
Citation Envoyé par Daniel60
Normalement les scripts du lien du #1 sont à jour(sauf https ?).
merci pour votre réponse Je l'ai mis à jour mais il y a toujours un problème apparemmen. le script copie_log_local.php5 ne s'effectue pas correctement.

Citation Envoyé par Daniel60
Il est probable qu'il faille modifier les chemins dans le script et dans le fichier .conf
En fait je n'utilise que le script copie_log_local.php5 pour récupérer les fichiers logs (qu'il faisait très bien avant) que j'analyse par la suite en local sur un analyseur de stats.
Quand vous parlez de modifier les chemins dans le script, vous parlez de quels chemins exactement ?

jalol
17/03/2007, 12h21
Bonjour à tous,

J'ai modifié les fichiers de l'archive awstats_config.zip ainsi que le présent HOWTO de manière à ce que tout fonctionne après les mises à jour d'OVH. Il ne devrait plus y avoir de problème en principe.

Pour ceux qui avaient déjà installé Awstats en suivant ce howto, vous devez modifier quelques fichiers :
  • copie_log_local.php5 : remplacez http par https
  • copie_log_local_full.php5 : idem
  • update_awstats.sh : Remplacez $HOME/login/cgi-bin/awstats par /home/votrelogin/cgi-bin/awstats. Attention, le /home n'est pas le même pour tout le monde (chez moi c'est /home.10), donc vérifiez votre chemin absolu avec la commande pwd en ssh ou avec la fonction real_path() en PHP


En espérant que ça vous aide.
Merci à Paul Popolipopo pour son aide concernant le fichier sh

Daniel60
17/03/2007, 08h13
Citation Envoyé par brunon
Salut,
finalement, y a-t-il quelque chose à changer dans le script du #4 ?
Parce ça ne fonctionne toujours pas cher moi sur un 90plan
merci
Normalement les scripts du lien du #1 sont à jour(sauf https ?).

P.S. : je le lance avec webcron ça fonctionnait bien avant le changement en https.
Le script se trouve donc dans le répertoire www/
Je ne sais pas si ça change quelque chose
Il est probable qu'il faille modifier les chemins dans le script et dans le fichier .conf

Daniel60
17/03/2007, 07h58
Citation Envoyé par Abogil
Les autres informations spécifiques dont j'ai besoin je me les fabrique et traite avec mes propres traces.
Idem, je me suis programmé un lecteur de logs.

Mox20
17/03/2007, 00h18
Citation Envoyé par Abogil
Tout dépend de ce que l'on entend par détaillé.
Les informations que j'obtiens me suffisent parfaitement.
Les autres informations spécifiques dont j'ai besoin je me les fabrique et traite avec mes propres traces.
Salut,
Par exemple quelle page a été visitée et vue tel jour etc…
Avoir des statistiques journalières détaillées, au lieu des statistiques mensuelles détaillées

Abogil
16/03/2007, 23h57
Citation Envoyé par Mox20
Est-ce que c’est possible d’avoir des statistiques journalières détaillées avec Awstats ?
Tout dépend de ce que l'on entend par détaillé.
Les informations que j'obtiens me suffisent parfaitement.
Les autres informations spécifiques dont j'ai besoin je me les fabrique et traite avec mes propres traces.

Mox20
16/03/2007, 23h38
Citation Envoyé par Mox20
Bonjour à tous,
Est-ce que c’est possible d’avoir des statistiques journalières détaillées avec Awstats ?

Merci d’avance pour votre aide
aucune solution ?

brunon
16/03/2007, 19h47
Salut,

finalement, y a-t-il quelque chose à changer dans le script du #4 ?

Parce ça ne fonctionne toujours pas cher moi sur un 90plan

merci

P.S. : je le lance avec webcron ça fonctionnait bien avant le changement en https.
Le script se trouve donc dans le répertoire www/
Je ne sais pas si ça change quelque chose

Raoul_s
16/03/2007, 18h56
Merci.

Mox20
16/03/2007, 16h04
Citation Envoyé par Raoul_s
À propos des scripts et de crontab, j'ai demandé à la hotline de rajouter mes scripts, comme indiqué dans le how-to.
Mais j'ai eu cette réponse : "Modifiez votre script svp, afin qu'il puisse être executé en php4, nos serveurs de cron n'execute pas le php5."

Que faire ?

Merci.
C’est bizarre ça, chez moi ça marche très bien en php5 sur un 90plan.

Mox20
16/03/2007, 16h01
Bonjour à tous,
Est-ce que c’est possible d’avoir des statistiques journalières détaillées avec Awstats ?

Merci d’avance pour votre aide

Daniel60
16/03/2007, 11h36
Voir plus haut #143 à #146

Raoul_s
16/03/2007, 11h28
À propos des scripts et de crontab, j'ai demandé à la hotline de rajouter mes scripts, comme indiqué dans le how-to.
Mais j'ai eu cette réponse : "Modifiez votre script svp, afin qu'il puisse être executé en php4, nos serveurs de cron n'execute pas le php5."

Que faire ?

Merci.

Mox20
15/03/2007, 22h08
D’accord, je vais voir si le script va s’exécuter normalement demain matin à 03h05, Je te remercie de m’avoir aidé Daniel60
@+

Daniel60
15/03/2007, 19h18
Oui, c'est cela.
Le script fonctionne apparemment, mais il n'y a rien de nouveau à traiter.

Mox20
15/03/2007, 17h03
Merci de m’avoir répondu, Daniel60,

J’ai modifié la ligne : my $DIRCONFIG = "/etc/awstats"; par my $DIRCONFIG ='.' ; , c’est bien ça . ?
Voici la réponse du script après la modification

Running '"./awstats.pl" -update -config=www.demaine.com -configdir="."' to update config www.domaine.com
Create/Update database for config "./awstats.www.domaine.com.conf" by AWStats version 6.6 (build 1.887)
From data in log file "/home.10.3/xxxxx/www/stats/apachelogs.log"...
Phase 1 : First bypass old records, searching new record...
Direct access after last parsed record (after line 6027)
Jumped lines in file: 6027
Found 6027 already parsed records.
Parsed lines in file: 0
Found 0 dropped records,
Found 0 corrupted records,
Found 0 old records,
Found 0 new qualified records.

Le script s exécute normalement ?

Merci d'avance pour votre aide.

Daniel60
15/03/2007, 16h34
Voir #2 et #4 de cette discussion

Mox20
15/03/2007, 16h14
Bonjour,
Je rencontre un problème avec le script : update_awstats.sh, lorsque je le teste avec putty, il me retourne l’erreur suivante : Error: Can't scan directory /etc/awstats.
Quelqu’un c’est de quoi s’agit-il ?

Merci d’avance pour votre aide.

j_b_poquelin
15/03/2007, 02h04
Pour moi aussi ça refonctionne. Merci !

Abogil
14/03/2007, 17h37
Cela refonctionne à nouveau. Merci Gilles.

Par pure curiosité :
- Quel était la cause du problème ?
- Quelle a été la correction ?

Raoul_s
14/03/2007, 15h37
Excellent ! Merci beaucoup.
Par contre il vaut mieux laisser le script en https ou en http ?

Gilles
14/03/2007, 15h32
Re,

C'est corrigé, vous pouvez utilisez vos scripts habituels.
par contre je vous conseil de mettre vos indentifants client sans aucune majuscule dans vos scripts.


@+ , Gilles

Pacmanito
14/03/2007, 15h29
yeahhhhhh !! ça remarche !!

Merci Gilles !

Pacmanito
14/03/2007, 14h04
idem.
merciiiiii !!

Raoul_s
14/03/2007, 14h01
Pareil. Merci d'avance.

Abogil
14/03/2007, 13h58
Bonjour Gilles,

Je viens de vous envoyer un mail privé.

Merci pour votre aide.

Gilles
14/03/2007, 13h00
Salut,

pour ceux qui ont un probleme de recuperation de leur logs , merci de me contacter en privé.
avec nom de domaine et le script utilisé.

merci !
gilles.

tzavdesign
14/03/2007, 07h31
J'ai suivi ce qu'a dit Daniel et chez moi c'est passé sans probleme.

J'ai bien rajouté https dans le copie_log_local.php
Il est bien dans la table de cron d'OVH (de toutes façon webcron ne fonctionne plus pour nous...)
Il s'est exécuté cette nuit sans probleme. PARFAITEMENT.

Par contre... avez-vous noté que les logs n'ont pas été compilés tous les jours par OVH ? En fait les logs des 4 derniers jours ont été compilés le 13, soit hier, pour nous sur la pluspart de nos plans (90, xxl et 240).

Le problème vient AUSSI de là.

Bonne chance !
David.

supernova34
13/03/2007, 12h05
J'ai moi aussi le même problème plus de stats en automatique.
Les travaux sur les logs sont terminé :
http://travaux.ovh.com/?do=details&id=1409

Que se soit en http ou en https le log fait zero ko.

Une solution serait la bienvenue, update des stats à la mano c'est pas au top !

a+

jim

vilou
13/03/2007, 11h11
Citation Envoyé par Raoul_s
J'ai essayé encore une fois, en modifiant des 2 lignes http en https dans le script copie_log_local.php, en le lançant avec http et avec https. Je reçois toujours l'email : "Stats OVH non exécutées, erreur dans le script..."

Concretement est ce qu'on peut dire au revoir à AWStats ?

Je rencontre exactement le même problême.

Raoul_s
13/03/2007, 10h33
J'ai essayé encore une fois, en modifiant des 2 lignes http en https dans le script copie_log_local.php, en le lançant avec http et avec https. Je reçois toujours l'email : "Stats OVH non exécutées, erreur dans le script..."

Concretement est ce qu'on peut dire au revoir à AWStats ?

Abogil
13/03/2007, 08h38
Citation Envoyé par Daniel60
Je confirme que le traitement des awstats quotidien s'opère normalement dès lors :
- que le script de récupération à été modifié avec les adresses en https
- que ce même script est lancé par la tâche cron d'OVH.
Où est-il écrit sur le site OVH que le script copie_log_local.php devait être impérativement lancé par la tâche cron d'OVH ?

Chez moi, avec ou sans "https:", copie_log_local.php ne fonctionne toujours pas. Octave, au secours!

j_b_poquelin
13/03/2007, 08h27
Vu que le fopen ne marche pas, j'ai essayé de trouver une solution alternative avec wget.

Mais évidemment si tu as la chance que ça marche chez toi, tu n'as pas de raison de t'en servir !

Daniel60
13/03/2007, 08h12
> j_b_poquelin

Je suis sur un 90plan et je n'utilise pas wget (pour quoi faire ?)

j_b_poquelin
13/03/2007, 08h05
Citation Envoyé par Daniel60
Bonjour,

Je confirme que le traitement des awstats quotidien s'opère normalement dès lors :
- que le script de récupération à été modifié avec les adresses en https
- que ce même script est lancé par la tâche cron d'OVH.

D'autre part, il peut maintenant aussi être lancé en ssh par 'php copie_log_local.php'.

Ceci bien sûr n'excuse en aucune manière la façon cavalière dont cette modif a été imposée.
Bonjour Daniel,

Merci pour ta réponse, mais je te confirme que le fopen avec https ne fonctionne pas sur mon 240Plan, ni sur mon 90Plan, et ce qu'on lance le script php depuis le ssh, le cron ou un navigateur. Le message d'erreur est le suivant :

function.fopen: failed to open stream: Connection refused

Si j'essaie de telecharger les logs avec wget depuis le SSH, j'ai le meme message. Par contre si je les récupère avec ma version locale de wget qui est sur mon pc cela fonctionne très bien, de meme que lors de l'accès à l'url des logs via un navigateur !

Peut-être pourrais-tu indiquer sur quel plan tu es ?

Daniel60
13/03/2007, 07h00
Bonjour,

Je confirme que le traitement des awstats quotidien s'opère normalement dès lors :
- que le script de récupération à été modifié avec les adresses en https
- que ce même script est lancé par la tâche cron d'OVH.

D'autre part, il peut maintenant aussi être lancé en ssh par 'php copie_log_local.php'.

Ceci bien sûr n'excuse en aucune manière la façon cavalière dont cette modif a été imposée.

j_b_poquelin
13/03/2007, 01h37
Citation Envoyé par shun
En attendant pour récupérer le fichier directement en ssh :
wget -O apachelogs.log.gz https://:@logs.ovh.net//logs-03-2007/-10-03-2007.log.gz
Citation Envoyé par dmd
Salut,
Sans doute un pb avec la connexion https. Le simple fait de changer http en https ne fonctionnera pas. La solution serait peut-etre de se tourner vers le CURL...
A creuser !
J'ai testé plusieurs possibilité mais il n'y a pas moyen de récupérer les logs avec un script. Ni avec wget en bash, ni avec fsockopen ou CURL en php (sur 240Plan).

Alors que j'ai la possibilité de télécharger avec ces fonctions des pages en SSL de mon propre site ou d'ailleurs, l'accès aux pages https://logs.ovh.net//osl/-.log ne fonctionne pas. OVH aurait-il bloqué volontairement le téléchargement des logs depuis ses propres serveurs ?

Après la suppression de l'accès à la crontab en SSH autour du 18 Janvier dernier (sujet dejà abordé dans ce thread), ça fait la deuxième regression importante sur les serveurs mutualisés. C'est très bien de passer le serveur des logs en SSL, car c'était assez abérrant de balancer en clair son NIC-HANDLE et son mot de passe à tout va pour récupérer les logs, mais on apprécierait de pouvoir les récupérer autrement que par un navigateur web...

Je ne veux pas dire du mal, car je suis globalement satisfait de l'hébergement, mais la je suis vraiment déçu... J'investis actuellement dans des prestations de référencement couteuses et j'aimerai pouvoir controler mes stats sans me farcir le téléchargement des logs à la main tous les matins...

tulipe44
12/03/2007, 15h17
Salut dmd,
Merci, mais quel est l'incidence de l'https sur mon problème ?
Je sollicite ce script en http.

tulipe44
12/03/2007, 14h42
Bonjour, depuis trois jours, le script copie_log_local.php5 ne fonctionne plus (240plan) ! Je n'ai rien modifié (ni fichiers, ni mots de passe). Que se passe-t-il ? Merci d'avance

mikro
11/03/2007, 13h57
Idem 720 plan

shun
11/03/2007, 12h41
Citation Envoyé par Abogil
Oui, c'est la meme erreur que les 2 messages précédents et qu'on ne peut rien faire pour l'instant. Si prier.
En attendant pour récupérer le fichier directement en ssh :
wget -O apachelogs.log.gz https://:@logs.ovh.net//logs-03-2007/-10-03-2007.log.gz

Puis gunzip apachelogs.log.gz et relancer le fichier update_awstats.sh

Daniel60
11/03/2007, 12h28
Citation Envoyé par Abogil
Oui, c'est la meme erreur que les 2 messages précédents et qu'on ne peut rien faire pour l'instant. Si prier.
Pourtant la tâche cron(OVH) a bien fonctionné à 6h30 alors que le lancement manuel échoue

Raoul_s
11/03/2007, 11h56
D'accord, merci.
J'en profite pour poser une question de néophite : c'est pas dangereux de mettre son nickhandle/pass dans le fichiers "copie_log_local.php5", comme ça ?
J'ai protégé le dossier par un .htaccess mais c'est suffisant ?

Abogil
11/03/2007, 11h52
Oui, c'est la meme erreur que les 2 messages précédents et qu'on ne peut rien faire pour l'instant. Si prier.

Raoul_s
11/03/2007, 11h50
Hello, je viens d'essayer d'installer AWStats avec ce super howto.
Mais j'ai l'erreur "Stats OVH non exécutées, erreur dans le script..." qui m'arrive par email quand je lance "copie_stats_local.php", je pense que c'est la meme erreur que les 2 messages précédents et qu'on ne peut rien faire pour l'instant ?

Merci.

Abogil
10/03/2007, 21h18
Citation Envoyé par Mox20
J'ai modifié les lignes suivantes dans le script "copie_log_local.php5", mais ça ne marche pas
Code:
	$urllog = "https://".$nichandle_ovh.':'.$pass_ovh."@logs.ovh.net/".$domaine_ovh."/".$replog."/".$log.'.gz';
	$urlosl = "https://".$nichandle_ovh.':'.$pass_ovh."@logs.ovh.net/".$domaine_ovh."/".$reposl."/".$log;
	$urlstats = "./".$log_local; // Le fichier log qui sera stocké en local sur le serveur
Moi aussi. Cela ne fonctionne pas.

Messieurs du développement OVH, pouvez éviter de faire des innovations le jeudi et de partir en congés WE.

Faites l'un ou l'autre, mais pas les DEUX en même temps.

Daniel60
10/03/2007, 20h44
Exact, pourtant ça passait hier et ce matin

Pacmanito
10/03/2007, 20h42
pareil, ça mouline

Mox20
10/03/2007, 20h13
J'ai modifié les lignes suivantes dans le script "copie_log_local.php5", mais ça ne marche pas
Code:
	$urllog = "https://".$nichandle_ovh.':'.$pass_ovh."@logs.ovh.net/".$domaine_ovh."/".$replog."/".$log.'.gz';
	$urlosl = "https://".$nichandle_ovh.':'.$pass_ovh."@logs.ovh.net/".$domaine_ovh."/".$reposl."/".$log;
	$urlstats = "./".$log_local; // Le fichier log qui sera stocké en local sur le serveur

Daniel60
10/03/2007, 19h41
J'ai donné la solution
il faut modifier le script avec l'adresse en https
et ça fonctionne

Pacmanito
10/03/2007, 19h17
pareil sur un 240

Mox20
10/03/2007, 18h11
Chez moi aussi depuis hier le fichier copie_stats_local.php ne marche plus sur un plan 90, vivement une solution.

Abogil
09/03/2007, 22h02
Citation Envoyé par Daniel60
. . . on peut obtenir maintenant, en demande manuelle, le message suivant :... et évidemment copie_stats_local.php se plante !
Je pense qu'il faut modifier le script avec l'adresse en https.
Chez moi aussi copie_log_local.php5 se plante sur mon 90plan. Je suis preneur de la correction.

Petite remarque : Il serait judicieux de la part d'OVH de nous donner cette correction qui est dùe à une modification unilatérale d'une fonctionnalité chez OVH.

Nota : OVH aurait pu maintenir une compatibilité ascendente comme cela est la règle en informatique.

Daniel60
09/03/2007, 21h45
Ceci pour attirer l'attention de ceux qui emploient cette procédure.
Suite aux travaux OVH sur les stats : http://travaux.ovh.com/?do=details&id=1409 on peut obtenir maintenant, en demande manuelle, le message suivant :
Vous êtes sur le point de vous connecter au site "logs.ovh.net" avec la nom d'utilisateur "xxxx" mais ce site web ne necessite pas d'authentification. Il peut s'agir d'une tentative pour vous induire en erreur...
(en Firefox)
... et évidemment copie_stats_local.php se plante !
Je pense qu'il faut modifier le script avec l'adresse en https.
A suivre

Daniel60
13/02/2007, 16h45
En crontab OVH il faut mettre l'extension php, car leur serveur n'est pas upgradé semble-t-il. Et cela marche très bien aussi !

Abogil
13/02/2007, 13h16
Citation Envoyé par is66
Mais apparament même si "copie_log_local.php5" a l'extension php5, il n'y a pas de fonction propre au php5, donc cela devrait passer.
Vous pouvez confirmez ?
Sur un 90plan, j'utilise le script copie_log_local.php5 une dizaine de fois par jour : Impeccable.

mikro
13/02/2007, 13h00
Citation Envoyé par is66
Bonjour et un grand merci pour ce tutorial.

J'ai tout installé sans trop de soucis.
J'ai donc fait une demande à OVH pour placer les 2 scrips en CRONTAB.
Voici leur réponse:



Mais apparament même si "copie_log_local.php5" a l'extension php5, il n'y a pas de fonction propre au php5, donc cela devrait passer.
Vous pouvez confirmez ?

Encore merci
IS
Pas de Pb, j'utilise copie_log_local.php sur un 720 plan déclenché par la crontab OVH.

Michel

is66
13/02/2007, 12h29
Bonjour et un grand merci pour ce tutorial.

J'ai tout installé sans trop de soucis.
J'ai donc fait une demande à OVH pour placer les 2 scrips en CRONTAB.
Voici leur réponse:

Nos crons n'accéptent ni mysql5 ni php5, vous pouvez convertir votre cron svp car il ne s'executera pas sinon.
Vers quel fichier dois-je envoyer le retour des crons ?
Mais apparament même si "copie_log_local.php5" a l'extension php5, il n'y a pas de fonction propre au php5, donc cela devrait passer.
Vous pouvez confirmez ?

Encore merci
IS

Abogil
22/01/2007, 08h19
Citation Envoyé par osgadou
et oui, plus de cron automatisé depuis 4 jours et j'ai le meme message que vous sur un crontab et à mon avis ils fouillent quand même le forum ovh. C 'est pas cool d'enlever comme ça sans prevenir. Vous auriez pu envoyer un mail!
Tu as deux solutions pour palier à ce type de mésaventures :
http://www.webcron.org/
http://www.dwalker.co.uk/phpjobscheduler/

Voir aussi :
http://forum.ovh.com/showpost.php?p=55976&postcount=94

osgadou
22/01/2007, 00h41
et oui, plus de cron automatisé depuis 4 jours et j'ai le meme message que vous sur un crontab e
a mon avis ils fouillent quand meme le forum ovh
c 'est pas cool denlever comme ca sans prevenir
vous auriez pu envoyer un mail!

mais bon, ceest la politik ovh.

reste plus qua contacter, on leur demande koi a ovh ?


(ou alors faire un second webcron sur cette adresse :

-http://www.mondomaine.com/cgi-bin/awstats.pl?config=www.mondomaine.com&framename=mai nright&update=1

mais la, cela veut dire que cette page n'est pas sécurisé par un htaccess)

Remi
11/01/2007, 03h08
Pour éviter de trier le fichier de logs avant traitement, il suffit de modifier un des paramètres au début de awstats.pl :

$NOTSORTEDRECORDTOLERANCE=250000;

Je le mets ainsi à 25 heures, ce qui couvre toute une journée.

Inconvénient : il faut penser à le modifier à chaque MAJ de Awstats

mikro
31/12/2006, 14h32
Citation Envoyé par jalol
Le deuxième, tu veux dire???
Non, le premier, passer par OVH pour faire exécuter le script sh.
C'est déjà écrit dans le tuto qu'il faut utiliser les chemins absolus...
J'ai du mal l'interpréter alors, j'avais cru que les modifs de chemins ne concernaient que le fichier de conf.
Les fichiers sh et pl devant simplement être placé là ou il faut et leur droits modifiés.

jalol
31/12/2006, 13h08
Aïe, apparemment OVH a revu sa politique de sécurité . Moi non-plus je n'ai plus accès à l'édition de la crontab, même pas à son listing. Reste donc à passer par le support technique pour leur demander l'ajout du script .sh à la crontab du serveur par eux... Par contre, on peut toujours passer par webcron pour le script PHP, mais bon, autant tout faire par OVH.

C'est dommage car c'était bien pratique . Ca me déçoit pour le coup

shun
31/12/2006, 12h34
Bonjour jalol, tu parles d'utiliser crontab -e mais pour moi avec mon 90plan je n'ai pas les droits semble-t-il :
mycodb@ssh1:~$ crontab -e
You (mycodb) are not allowed to use this program (crontab)
See crontab(1) for more information

Est-ce normal ou faut-il faire qqc pour avoir ces droits ?
Merci,

Shun

jalol
31/12/2006, 11h25
Ma remarque concernait le premier cas
Le deuxième, tu veux dire???

C'est déjà écrit dans le tuto qu'il faut utiliser les chemins absolus... Par contre, on ne peut pas exécuter des scripts .sh via Webcron, c'est normal, c'est une mesure de sécurité d'OVH. Voilà pourquoi il faut éditer la crontab manuellement avec Putty pour le script .sh avec crontab -e, comme je l'ai expliqué dans le tuto

mikro
31/12/2006, 10h46
Citation Envoyé par jalol
Je n'ai pas bien compris le message qu'il faut que j'ajoute dans le tuto . Dis-moi et je le mets.
Je rappelle juste une chose, que j'avais bien écrit dans le tuto, mais qui peut paraître un peu floue . J'ai évoqué 2 manières de mettre à jour les stats tous les jours :
  • Passer par le support technique d'OVH
  • Se débrouiller tout seul avec Putty et Webcron
Ma remarque concernait le premier cas. Lors de l'execution via le webcron d'OVH, le script sh qui fonctionne parfaitement en ligne de commande sous putty ne peut être utilisé tel quel, il faut transformer les chemins relatifs en chemins absolus.
Ceci aussi bien lors de l'appel du script pl dans le .sh
#!/bin/bash
perl /home/loginovh/cgi-bin/awstats_updateall.pl -awstatsprog=/home/itemssi/cgi-bin/awstats.pl now
que dans le script pl lui-même :
my $DIRCONFIG = "/home/loginovh/cgi-bin";

jalol
31/12/2006, 00h32
Il faudrait, je pense mettre une petit message dans le tuto
Je n'ai pas bien compris le message qu'il faut que j'ajoute dans le tuto . Dis-moi et je le mets.
Je rappelle juste une chose, que j'avais bien écrit dans le tuto, mais qui peut paraître un peu floue . J'ai évoqué 2 manières de mettre à jour les stats tous les jours :
  • Passer par le support technique d'OVH
  • Se débrouiller tout seul avec Putty et Webcron

Dans le premier cas, il suffit de passer par le support technique d'OVH et leur demander d'ajouter les 2 fameux fichiers à ajouter à leur CRON à des horaires décalés. ATTENTION !!! J'ai remarqué que la récupération des logs ne fonctionnent pas bien à certaines heures, je reçois des mail d'erreurs parfois... Par sécurité (et liberté faut le dire ), je préfère la deuxième solution qui consiste à passer par Putty et la ligne de commande SSH et Webcron. Webcron permet de récupérer les logs via le script PHP (à exécuter vers 2h00 du matin). Putty permet d'accéder à la ligne de commande du serveur pour ajouter soi-même le fichier .sh à la crontab (vers 3h00 du matin).

Si je peux apporter ma contribution, voici le script copie_log_local_jour.php5 qui permet de récupérer les anciennes stats. A mettre dans votre répertoire stats.
Je viens d'ajouter ta contribution au tuto. J'en ai même profité pour ajouter ton script dans le .zip que je propose en téléchargement. Merci beaucoup pour ta contribution, je pense que ça va en aider pas mal .
Voilou

shun
28/12/2006, 14h51
Merci pour ce Howto.

Si je peux apporter ma contribution, voici le script copie_log_local_jour.php5 qui permet de récupérer les anciennes stats. A mettre dans votre répertoire stats.

Code:
#!/usr/local/bin/php
 0) {
	$pastdate=date('d-m-Y',strtotime('now -'.$jour.' days'));
	$log = $domaine_ovh."-".$pastdate.".log"; // Nom du log de aujourd'hui-jour
	$pastrepdate=date('m-Y',strtotime('now -'.$jour.' days'));
	$replog = "logs-".$pastrepdate; // Répertoire du log de aujourd'hui-jour
	$reposl = "osl";

	// Les adresses pour récupérer les logs bruts à jour
	// Ces adresses sont sous la forme http://votrenichandle:votrepass@log...ire/fichier_log
	$urllog = "http://".$nichandle_ovh.':'.$pass_ovh."@logs.ovh.net/".$domaine_ovh."/".$replog."/".$log.'.gz';
	$urlosl = "http://".$nichandle_ovh.':'.$pass_ovh."@logs.ovh.net/".$domaine_ovh."/".$reposl."/".$log;
	$urlstats = "./".$log_local; // Le fichier log qui sera stocké en local sur le serveur

	// Ouverture des fichiers logs distants. Les logs archivés sont au format gz
	$fdistlog = @gzopen($urllog, "r"); // Le log archivé
	$fdistosl = @fopen($urlosl, "r"); // Le log OSL
	
	$error = false;

	if($fdistlog) { // Si on arrive à ouvrir le fichier archivé
	  $url  = $fdistlog;
	  $type = 'gz';
	} elseif($fdistosl) { // Si on arrive à ouvrir le fichier OSL
	  $url  = $fdistosl;
	  $type = 'f';
	} else $error = true; // On arrive à ouvrir aucun des 2 fichiers

	if(!$error) { // S'il n'y a pas d'erreur, on parcourt le fichier
	  $i=0;
	  $tabligne=array();
	  if ($type == 'gz') { // On travaille sur l'archive, il faut donc utiliser gz
	  	echo "Traitement de l'archive $pastdate... ";
	    while (!gzeof($url)) {
	      $ligne = @gzgets($url, 2048);
	      list($IP, $host, $user, $date, $other)=split(" ", $ligne);
	      $tabligne[$date.':'.sprintf("%05d", $i)]=$ligne;
	      $i++;
	    }
	  }
	  elseif ($type == 'f') { // On travaille sur le fichier OSL
	  	echo "Traitement du log osl $pastdate... ";
	    while (!feof($url)) {
	      $ligne = @fgets($url,2048) ;
	      list($IP, $host, $user, $date, $other)=split(" ", $ligne);
	      $tabligne[$date.':'.sprintf("%05d", $i)]=$ligne;
	      $i++;
	    }
	  }
	  ksort($tabligne) ;
	  
	  foreach($tabligne as $ligne) {// On écrit la totalité du log dans le fichier log local
	    fputs($floc,$ligne) ;
	  }
	  echo "Fichier $log traité.
\n"; } else { // Erreur, on n'a pas réussi à ouvrir un seul fichier log distant echo "Fichier $log non trouvé !
\n"; } // On ferme les fichiers @gzclose($fdistlog); @fclose($fdistosl); $jour--; } @fclose($floc); ?>
Pour récupérer les stats depuis 30 jours : http://votresite/stats/copie_log_loc...r.php5?jour=30

NB : Si vous avez déjà compilé des statistiques pour un mois donné et qu'il vous manque celles du début du mois, effacer les fichiers awstats*.txt dans cgi-bin avant de relancer update_awstats.sh

mikro
26/12/2006, 23h05
Le sh fonctionnait aussi en console (sous putty) mais pas une fois déclenché par le cron OVH.

Le script php a été mis dans le cron par OVH, je suis passé par le support technique.

osgadou
26/12/2006, 19h38
mikro jai pas tres bien compris ton message, mais c'est pas grave car chez moi le script SH fonctionne avec un point ds le chemin

mais ma question est la suivante : le script PHP tu l'as mis dans le cron SSH d'ovh tout seul comme un grand, ou tu es passé par eux ?
si c'est la 2eme solution, je prefere rester sous webcron.

mikro
26/12/2006, 19h17
Confirmation

Les scripts sh et pl fonctionnent maintenant correctement. Les chemins doivent impérativement être en absolu aussi bien pour le script sh (j'ai précisé aussi en paramètre le chemin du programme).

#!/bin/bash
perl /home/loginovh/cgi-bin/awstats_updateall.pl -awstatsprog=/home/itemssi/cgi-bin/awstats.pl now >>/home/loginovh/cgi-bin/trace.log
que dans le script pl

my $DIRCONFIG = "/home/loginovh/cgi-bin";
Je rappelle que le script php, dès le début a fonctionné appelé par le cron. Il n'est donc pas nécessaire de passer par Webcron.

Tout fonctionne donc correctement pour moi (720 plan) depuis 2 jours. Il faudrait, je pense mettre une petit message dans le tuto.

osgadou
26/12/2006, 16h55
en effet ca ne marche pas avec /etc/...

il faut remplacer ce chemin par un point .

ensuite lance le script pour voir si ca se lance correctement, si oui, c'est bon

verifie le cron (sh) qui doit se lancer 1h après au moins celui de webcron (php)

Le cron du ssh sert a lancer le .sh
le cron de webcron sert a lancer le fichier php

tzavdesign
26/12/2006, 16h52
En attendant le retour de Mikro,

comme lui nous pouvons executer en SSH le script update_awstats.sh qui lance updateall.pl sans probleme et compile les stats, mais pas possible de l'executer correctement en CRON.

Nous avons essayé de mettre le chemin absolu dans awstats_updateall.pl comme il l'a suggéré.
RIEN.
Ensuite nous avons remis le texte original (/etc/awstats je crois).
RIEN.
D'apres webcron, le lancement de update_awstats.sh se fait bien à l'heure, mais retourne une erreur 500 - comme quand on essaye de le lancer depuis un navigateur.

Faut-il en conclure que les heureux détenteurs d'un XXLplan sont bien malchanceux et qu'il est impossible de finaliser l'automatisation des mises à jour d'awstats sur ce plan ???

C'eût été trop beau. Et maintenant je commence vraiment à avoir une dent contre OVH qui ne propose AUCUNE stats correctes. Et qui nous donne l'impression de s'en moquer. Et on a pris le plan le plus cher en se disant...

Merci aux usagers de ce forum pour leur participation et leur aide en tous cas !!!

osgadou
24/12/2006, 10h50
Citation Envoyé par osgadou
bon jai fait un ssh
et la commande ecrit en premiere page

et inscription sur webcron pour le php

on verra cette nuit
bon je confirme que ca marche impec

scipt php sur webcron
+
script en ssh

les awstats multidomaines sont mis a jour
merci pr le tuto

mikro
21/12/2006, 09h20
A priori, le script déclenché par la crontab s'execute sur une autre machine que celle ou est situé le script.

Le script pl est donc incapable de retrouver les fichiers de conf sur "."

Je change les chemins en absolu et j'attends demain pour confirmer ce point.

osgadou
21/12/2006, 08h57
bon jai fait un ssh
et la commande ecrit en premiere page

et inscription sur webcron pour le php

on verra cette nuit

osgadou
21/12/2006, 02h08
salut et merci pour le tuto en premiere page ca a fonctionne en 10mn

enfin jai pas compris la fin, jai lu les 13 pages, mais je ne comprends pas

donc si quelqu un peu mexpliquer exactement ce quil faut faire pour que demain et les autres jours tout soit automatisé????

Merci

mikro
14/12/2006, 18h58
Citation Envoyé par yanngarbage
Hello, je suis de passage, et je viens de penser a un truc sur la cmde update_awstats.sh

As tu essayer d'utiliser le mode debug d'awstats.
Dans le fichier de config, tu as un parametre a mettre a 1 pour cela. tu auras peut etre des infos sur le probleme.

a+

yann
Oui mais sans succes.
J'ai aussi redirigé la sortie vers un fichier de log
perl awstats_updateall.pl now >>trace.log
Mais le matin suivant, aucun fichier trace n'a été généré.
Ou alors a été généré qqpart sur un serveur OVH auquel je n'ai pas accés.
La hotline, après recherche me signale que après un test à partir de leur machine, il y a un message d'erreur :
/home/itemssi/cgi-bin/update_awstats.sh: trace.log: Permission non accordée
Command exited with non-zero status 1
Je ne vois pas pourquoi !
Le script s'execute sous putty (login : itemssi) sans aucun pb
Les droits affectés sont cohérents avec cet hébergement et ce domaine.
Tous les fichiers et scripts de ce répertoire ont les même droits

sur mon serveur, les droits me semblent corrects
-rwxr-xr-x 1 itemssi users 54 Dec 11 21:03 update_awstats.sh
-rwxr-xr-x 1 itemssi users 5191 Nov 20 17:0 awstats_updateall.pl

yanngarbage
14/12/2006, 12h56
Hello, je suis de passage, et je viens de penser a un truc sur la cmde update_awstats.sh

As tu essayer d'utiliser le mode debug d'awstats.
Dans le fichier de config, tu as un parametre a mettre a 1 pour cela. tu auras peut etre des infos sur le probleme.

a+

yann

mikro
08/12/2006, 15h38
Oui, en appel avec fopen cela fonctionne.

Je trouve qd même génant d'être obliger de déclencher l'exécution d'un script perl par la fonction fopen mais bon si cette manip permet de récupérer les stats antérieures.

Confirmation : J'ai substitué cette commande à exec dans le script updatestats.php.
J'ai pu (en changeant à chaque fois l'appel) récuprérer toutes les stats pour chacun des multidomaines (5 en tout) pour certain depuis 6 mois.

maintenant, l'appel en cron de update_awstats.sh devrait faire la mise à jour or cela ne fonctionne pas en cron.
Il me faut régler ce Pb.

utiliser un fichier php (avec la commande fopen) ne me satisfait pas car dans ce cas il devient impossible de protéger l'accès aux stats par un .htaccess sans bloquer la mise à jour auto.

Abogil
08/12/2006, 09h58
Merci Yann et Mikro,

Je viens de légèrement retoucher vos travaux, et chez moi, cela fonctionne bien.

Code PHP:
#!/usr/local/bin/php

$ret = array();
$URL "http://www.tondomaine.com/cgi-bin/awstats.pl?framename=mainright&update=1";
$Fhd_URL fopen($URL,"r");
if (
$Fhd_URLfclose($Fhd_URL);

echo 
" Commande effectuee : \$Fhd_URL = fopen($URL,\"r\");"
;
?>

mikro
08/12/2006, 07h58
Bonjour Yann

Citation Envoyé par yanngarbage
Je n'ai pas compris pourquoi ce probleme se posait.
en exec avec du php, il se pose le probleme suivant:
tu copies en local le fichier de log.
la commande exec(cmde php), lance la mise a jour des stats avec le protocole http.
Puis tu executes cela sur un second fichier de log.
Et la exec est lance une seconde fois.
Il s'avere que la deuxieme cmde exec peut etre lance alors que le calcul de la premiere n'est pas terminee.
Tu perds alors des données.
C'est du moins ce que j'avais remarque ds mes tests.
Je ne crois pas, le test que j'ai effectué avec un script php simple do_perl.php
#!/usr/local/bin/php

$ret = array();
$commande = "/home/itemssi/cgi-bin/awstats.pl -config=www.items-si.fr -update=1"; //la commande perl a executer
exec($commande, $ret);
echo "
commande effectuée : ".$commande."
";
print_r($ret);
?>
Qui isole une commande exec pour le traitement d'un seul apachelogs.log montre que le Pb est ailleurs et infirme ton hypothèse.

La cmde etait peut-etre fopen(url d'update) ou open(url update), tout simplement sans exec.
Avec fopen, le fichier est bien traité (génération du fichier awstatsxx2006.www.items-si.fr.txt dans cgi-bin ) mais apparemment mon script modifié do_perl.php a du mal a se terminer.
#!/usr/local/bin/php

$ret = array();
$commande = "/home/itemssi/cgi-bin/awstats.pl -config=www.items-si.fr -update=1"; //la commande perl a executer
//exec($commande, $ret);
$fileweb = fopen("http://www.items-si.fr/cgi-bin/awstats.pl?update=1&debug=1&framename=mainright&co nfig=www.items-si.fr","r");
if ($fileweb) fclose($fileweb);
echo "
commande effectuée : ".$commande."
";
//print_r($ret);
?>
Ce qui présume mal du traitement qd il sera dans une boucle.

yanngarbage
07/12/2006, 17h42
C'est bien ce point que je trouve étrange et que j'aimerai comprendre, OVH ??
Je n'ai pas compris pourquoi ce probleme se posait.

Oui, qui est en fait l'url précisée dans l'interface de AWSTAT quand on veut effectuer la mise à jour manuellement.
Mais dans le script tu ne peut pas faire un exec, un header("location ...") ne donne rien.
Ca avait marché chez moi mais je ne peux pas verifier la syntaxe exacte, je ne suis pas chez moi.

Il n'y a pas plusieurs fichiers de log. Au moment de l'exécution de ce script perl, seul un fichier apachelogs.log est analysé.
Ensuite on écrase ce fichier avec celui correspondant au jours suivant et on refait appel au script perl.
en exec avec du php, il se pose le probleme suivant:
tu copies en local le fichier de log.
la commande exec(cmde php), lance la mise a jour des stats avec le protocole http.
Puis tu executes cela sur un second fichier de log.
Et la exec est lance une seconde fois.
Il s'avere que la deuxieme cmde exec peut etre lance alors que le calcul de la premiere n'est pas terminee.
Tu perds alors des données.
C'est du moins ce que j'avais remarque ds mes tests.

La cmde etait peut-etre fopen(url d'update) ou open(url update), tout simplement sans exec.
Je verifierai des que je peux.

mikro
07/12/2006, 16h13
Bonjour Yann

Citation Envoyé par yanngarbage
Salut,

la cmd exec "/home/itemssi/cgi-bin/awstats.pl -config=www.items-si.fr -update=1"; pose probleme si tu le fais au travers d'un navigateur.
Je me souviens que j'avais rencontre des pbs similaires.
C'est bien ce point que je trouve étrange et que j'aimerai comprendre, OVH ??

De memoire, j'avais utilise la solution qui etait de donner la commande suivante:
http://www.items-si.fr/cgi-bin/awsta...right&update=1
dans le script.
Oui, qui est en fait l'url précisée dans l'interface de AWSTAT quand on veut effectuer la mise à jour manuellement.
Mais dans le script tu ne peut pas faire un exec, un header("location ...") ne donne rien.

Mais faire cela par http pose probleme si tu l'executes pour plusieurs fichiers de logs..
tu lance plusieurs fois la cmde http://www.items-si.fr/cgi-bin/awsta...right&update=1 qui tournent en parallele.
aswatst gerant mal l'acces en concurence des fichers de stats, tu rencontres des pertes de données.
Il n'y a pas plusieurs fichiers de log. Au moment de l'exécution de ce script perl, seul un fichier apachelogs.log est analysé.
Ensuite on écrase ce fichier avec celui correspondant au jours suivant et on refait appel au script perl.

Par contre il peut y avoir plusieurs appels au même fichier suivant le domaine étudié.
mais pour l'instant même pour traiter un seul domaine, cela ne marche que manuellement lors du clic sur le lien de l'interface AWSTATS c à d pour un fichier apachelogs.log d'un jour particulier.

Il faut que tu decides de ton besoin en fonction de ton porcessus de mises a jour.
J'ai l'impression de ne pas avoir grand chose à décider. Aucune des solutions proposées en fonctionne dans mon environnement.

Sauf le copie_log_local.php qui tous les jours me constitue un fichier apachelogs.log correct qu'il faut traiter manuellement ou en ligne de commande sous putty ou le script updatestats.php qui génère successivement les apachelos.log correspondant à la période voulu sans effectuer acun traitement.

Absurde ou ingérable donc,

yanngarbage
07/12/2006, 15h49
Salut,

la cmd exec "/home/itemssi/cgi-bin/awstats.pl -config=www.items-si.fr -update=1"; pose probleme si tu le fais au travers d'un navigateur.
Je me souviens que j'avais rencontre des pbs similaires.
De memoire, j'avais utilise la solution qui etait de donner la commande suivante:
http://www.ton-site/cgi-bin/awstats....right&update=1
dans le script.

Mais faire cela par http pose probleme si tu l'executes pour plusieurs fichiers de logs..
tu lance plusieurs fois la cmde http://www.ton-site/cgi-bin/awstats....right&update=1 qui tourne en parallele.
aswatst gerant mal l'acces en concurence des fichers de stats, tu rencontres des pertes de données.

Il faut que tu decides de ton besoin en fonction de ton processus de mises a jour.

mikro
06/12/2006, 11h39
Pour essayer d'y voir plus clair, j'ai créé un fichier php tout simple
#!/usr/local/bin/php

$ret = array();
$commande = "/home/itemssi/cgi-bin/awstats.pl -config=www.items-si.fr -update=1"; //la commande perl a executer
exec($commande, $ret);
echo "
commande effectuée : ".$commande."
";
print_r($ret);
?>
je supprime tous les fichiers awstatsxx2006.www.items-si.fr.txt de cgi-bin

Ne reste donc que le fichier apachelogs.log dans le répertoire stats.

Vérification : sous awstats aucune stat,
Dernière mise à jour: Jamais mis à jour
J'execute mon fichier php :
commande effectuée : /home/itemssi/cgi-bin/awstats.pl -config=www.items-si.fr -update=1
Array ( [0] => Content-type: text/html; charset= [1] => Cache-Control: public [2] => Last-Modified: Wed Dec 6 10:30:46 2006 [3] => Expires: Wed Dec 6 10:30:46 2006 [4] => [5] => [6] => [7] => [8] => [9] => [10] => [11] => [12] => [13] => [14] => [15] => [16] => [17] => [18] => [22] => [23] => [24] => )
Le script perl est donc bien éxécuter mais cela n'a aucun effet, le fichier awstatxx2006...txt n'est pas généré

je lance la même commande sous ssh

le fichier est généré, les stats sont accessibles. ???

tzavdesign
06/12/2006, 10h03
Salut,

meme probleme. Sur XXLplan, le update_awstats.sh est dans le cron d'OVH, mais il ne se passe rien : les nouveaux logs téléchargés automatiquement par copie_log_local.php ne sont pas implémentés. Alors qu'ils le sont si on lance le script en SHELL.

Testé et apparemment lancé par WEBcron, meme probleme, il ne compile pas les stats.

Alors là, comment lancer ce script ? ou bien comment lancer awstats_updateall.pl ?

On est completement bloqués !

Merci pour ceux qui y verront de la lumière
David.

mikro
06/12/2006, 08h17
Citation Envoyé par yanngarbage
Et bien, ce script permet de mettre a jour les bases awstats depuis plusieurs mois, ce qui posait probleme pour de nombreuses personnes ici.
Oui, Yann, j'ai bien compris tout l'intérêt de ce script mais sa fonction est d'être exécuté la première fois, ensuite il ne faut que faire la maj journalière, n'est ce pas ?


Si exec echoue, cela peut venir:
1) de ton fichier de conf awstats.
2) du fichier lastdayupdate.txt, qui a ete mis a jour apres une premier lancement. Pensez a renseigner la bonne date avant de le relancer.
3) des fichiers awstatsxx2006xxx.txt qui n'ont pas ete effaces avant de lancer le script
1) Non puisque en ligne de commande ou par un clic sur "mise a jour immédiate" la maj s'effectue à partir du fichier apachelogs.log présent.
2) Non plus car lastdayupdate.txt n'intervient que pour générer des apachelogs.logs successifs avant leur traitement par exec. Ce qui fonctionne chez moi (j'ai effectué plusieurs simulations en stoppant sur un jour donné).
3) Non pour la même raison que 2


J'ai effectué un nouveau test ce matin, sans toucher au lastdayupdate.txt modifié hier en tracant la commande exec mais en supprimant les fichiers awstatxxx_xx.txt.

Nb de fichiers:1 Mis a jour de: logs-12-2006/items-si.fr-05-12-2006.log ok update awstats....
commande : /home/itemssi/cgi-bin/awstats.pl -config=www.items-si.fr -update=1
update done
Ensuite de retour sous l'interface d'awstats, aucun enregistrement n'était intégré,
Dernière mise à jour: Jamais mis à jour (Voir 'Build/Update', page awstats_setup.html)
Pourtant en executant directement sous putty la même commande perl
itemssi@ssh1:~/www/stats$ perl /home/itemssi/cgi-bin/awstats.pl -config=www.items-si.fr -update=1
Update for config "/home/itemssi/cgi-bin/awstats.www.items-si.fr.conf"
With data in log file "/home/itemssi/www/stats/apachelogs.log"...
Phase 1 : First bypass old records, searching new record...
Searching new records from beginning of log file...
Phase 2 : Now process new records (Flush history on disk after 20000 hosts)...
Jumped lines in file: 0
Parsed lines in file: 634
Found 486 dropped records,
Found 1 corrupted records,
Found 0 old records,
Found 147 new qualified records.
itemssi@ssh1:~/www/stats$
Cette fois ci tout rentre dans l'ordre et sous awstats j'ai maintenant :
Dernière mise à jour: 06 Déc 2006 - 08:02
Mon Pb reste donc entier, pour quelle raison la commande exec n'aboutit pas dans le script php ?

Apache a bien les droits d'execution sur le script perl
-rwxr-xr-x 1 itemssi users 544954 Nov 13 14:10 awstats.pl

yanngarbage
05/12/2006, 23h49
Et bien, ce script permet de mettre a jour les bases awstats depuis plusieurs mois, ce qui posait probleme pour de nombreuses personnes ici.

De plus, c'est un script qui marche en cron sur ovh, ce qui semblait poser probleme pour certaines personnes, qui dependait d'autres outils pour le faire (webcron), donc plus besoin de mise a jour manuelle.

Si exec echoue, cela peut venir:
1) de ton fichier de conf awstats.
2) du fichier lastdayupdate.txt, qui a ete mis a jour apres une premier lancement. Pensez a renseigner la bonne date avant de le relancer.
3) des fichiers awstatsxx2006xxx.txt qui n'ont pas ete effaces avant de lancer le script

mikro
05/12/2006, 17h51
Bonsoir Yann

Dans ce cas, quel est l'avantage par rapport à la solution :

Executer ton script d'export manuellement via le navigateur (cela est-il possible ?)
ensuite conserver la procédure du how to initial avec d'une part le déclenchement de copie_log_local.php puis awstats.sh ?

pour un execution manuelle via apache et après divers test, les fichiers apachelogs.log successifs sont bien créés, et sont "digérables" par awstats qd on prends soin de virer les awstatsxx2006xxx.txt présents dans le rep cgi-bin et que l'on lance l'udpate via l'interface de awstats
(tests effectué au hasard sur dee fichiers concernant des jours précédents.

Par contre la commande exec(/home/login/cgi-bin/awstats.pl -config=www.items-si.fr -update=1") ne fait rien du tout sous mon environnement.

A l'issue du script, de retour sous l'interface de awstats j'ai
Dernière mise à jour: Jamais mis à jour (Voir 'Build/Update', page awstats_setup.html)




Question subsidiaire ?
Pour quelle raison, dans le script copie_log_local.php l'appel par exec à awstats.sh n'est pas inclus ?

Michel

yanngarbage
05/12/2006, 17h27
Michel,

dans ce cas la, la solution est la suivante:
Creer le fichier lastdayupdate.txt en mettant la date de depusi laquelle tu veux recuperer les données, moins un jour.
Lors de la premiere execution du script en cron, toutes les logs apache seront recuperees.
Et le lendemain, seule la log necessaire sera recuperee.

mikro
05/12/2006, 17h24
Eh bien non ! mauvaise nouvelle.

Sur certains plans (720 plans) il n'est pas possible d'exécuter ce script en ssh.

Réponse de la hot line OVH :

Le probléme avec le serveur ssh ne se situe pas au niveau de sa version mais de sa configuration.
En fait nous interdisons l'ouverture de socket, donc tout appel à une url ne fonctionnera pas depuis nos serveurs ssh.


en cron, il doit fonctionner car copie_log_local.php fonctionne.

Michel

yanngarbage
02/12/2006, 21h55
Un petit message pour indiquer que j'ai enfin les fonctionnalites :
1 - un script d'initialisation d'une base d'awats par rapport aux logs apache, a partir d'une date donne a la veille
2 - ce meme script gere l'update par cron chez ovh chaque jour a 2h du matin.

Des que j'ai un peu plus de temps, je fais une petite doc.
Mais je peux vs fournir les scripts et la methodo au besoin.

Donc voici le script:
Code PHP:
#!/usr/local/bin/php


$domaine_ovh   
'XXXX'// Votre domaine principal. Ne pas mettre les www

$nichandle_ovh 'XXXX'// Votre Nic-Handle OVH

$pass_ovh      'XXXX'// Votre mot de passe OVH (celui qui vous permet d'aller ? l'admin OVH

$commande      "./awstats.pl -config=XXXX -update=1"//la commande perl a aexecuter

$log_local     '/home/XXXX/www/stats/apachelogs.log'// le chemin du fichier de log local

$file_last_update "/home/XXXX/cgi-bin/lastdayupdate.txt";// le chemin du fichier contentant la date du dernier fichier de log mis a jour

$lastday               strftime("%d-%m-%Y",mktime(-1));// la veille
$lastdayupdate         ""// dernier update des stats
$fp fopen($file_last_update,"r");
if (
$fp){
    
$lastdayupdate fgets($fp);
    
fclose($fp);
}
    

$dateld explode("-",$lastday);
$dateldu explode("-",$lastdayupdate);

$ok 0;
if (
intval($dateld[2])==intval($dateldu[2])){ // num de l annee de la veile superieur au last update
    
if (intval($dateld[1])>intval($dateldu[1])) // num du mois de la veile superieur au last update
        
$ok 1;
    else 
        if(
intval($dateld[1])==intval($dateldu[1])) // num du mois de la veile superieur au last update
            
if (intval($dateld[0])>intval($dateldu[0])) // num du jour de la veile superieur au last update
                
$ok 1;
}
else 
    if (
intval($dateld[1])>intval($dateldu[1]))
        
$ok 1;
        
if (
$ok==1){    
    
$listefileslogs = array();
$listefilesosl = array();

$stop =0;
$j intval($dateldu[0])+1;
$m intval($dateldu[1]);
$a intval($dateldu[2]);

while (!
$stop){
    
    if (
checkdate($m,$j,$a)){
        
$valdate strftime("%d-%m-%Y",mktime(0,0,0,$m,$j,$a));
        
$valdate1 strftime("logs-%m-%Y",mktime(0,0,0,$m,$j,$a))."/".strftime($domaine_ovh."-%d-%m-%Y.log",mktime(0,0,0,$m,$j,$a));
        
$valdate2 strftime("osl/".$domaine_ovh."-%d-%m-%Y.log",mktime(0,0,0,$m,$j,$a));
        
array_push($listefileslogs,$valdate1);
        
array_push($listefilesosl,$valdate2);

        if (
strcmp($valdate,$lastday)==0){
            
$stop 1;
            
$fp fopen($file_last_update,"w+");
                if (
$fp){
                    
fwrite($fp,$lastday);
                    
fclose($fp);
                }
        }
    }
    
$j++;
    if (
$j==32){
        
$j=1;
        
$m++;
        if (
$m==13){
            
$m=1;
            
$a++;
        }
    }    
}

$nbfiles count($listefileslogs);
echo 
"Nb de fichiers:".$nbfiles."\n";
for (
$posfile=0;$posfile<$nbfiles;$posfile++){
    echo 
"Mis a jour de: ".$listefileslogs[$posfile]."\n";

    
// Le nom du fichier local qui contiendra le dernier log ? jour. C'est le nom de ce fichier qu'il faut renseigner dans le fichier conf de AWStats awstats.votresite.com.conf



    
$valfile1 strftime("logs-%m-%Y",mktime(0,0,0,$m,0,$a))."/".strftime($domaine_ovh."-%d-%m-%Y.log",mktime(0,0,0,$m,$j,$a));
    
$valfile2 strftime("osl/".$domaine_ovh."-%d-%m-%Y.log",mktime(0,0,0,$m,$j,$a));
    
$urllog =  "http://".$nichandle_ovh.':'.$pass_ovh."@logs.ovh.net/".$domaine_ovh."/".$listefileslogs[$posfile].'.gz';
    
$urlosl "http://".$nichandle_ovh.':'.$pass_ovh."@logs.ovh.net/".$domaine_ovh."/".$listefilesosl[$posfile];

    echo 
$urllog."\n";
    echo 
$urlosl."\n";

    
// Ouverture des fichiers logs distants. Les logs archiv?s sont au format gz

    
$fdistlog = @gzopen($urllog"r"); // Le log archiv?

    
$fdistosl = @fopen($urlosl"r"); // Le log OSL

    
$error false;

    if(
$fdistlog) { // Si on arrive ? ouvrir le fichier archiv?

          
$url  $fdistlog;

          
$type 'gz';

    } elseif(
$fdistosl) { // Si on arrive ? ouvrir le fichier OSL

          
$url  $fdistosl;

          
$type 'f';

    } else 
$error true// On arrive ? ouvrir aucun des 2 fichiers



    
if(!$error) { // S'il n'y a pas d'erreur, on parcourt le fichier
        
        
echo "ok\n";

        
$i=0;

          
$tabligne=array();

        if (
$type == 'gz') { // On travaille sur l'archive, il faut donc utiliser gz

            
while (!gzeof($url)) {

                  
$ligne = @gzgets($url2048);

                list(
$IP$host$user$date$other)=split(" "$ligne);

                  
$tabligne[$date.':'.sprintf("%05d"$i)]=$ligne;

                  
$i++;

            }
        }

          elseif (
$type == 'f') { // On travaille sur le fichier OSL

            
while (!feof($url)) {

                  
$ligne = @fgets($url,2048) ;

                  list(
$IP$host$user$date$other)=split(" "$ligne);

                  
$tabligne[$date.':'.sprintf("%05d"$i)]=$ligne;

                  
$i++;

            }
        }

          
ksort($tabligne) ;

          
$floc = @fopen($log_local,"w+") ;

          foreach(
$tabligne as $ligne) {// On ?crit la totalit? du log dans le fichier log local

            
fputs($floc,$ligne) ;

          }
          
//@mail("webmaster@".$domaine_ovh,"[ OK ] CRON Stats-OVH --> OK","Stats OVH OK ex?cut?es correctement"); // Envoi d'un mail de confirmation

    
}

    else { 
// Erreur, on n'a pas r?ussi ? ouvrir un seul fichier log distant

        
echo "erreur -1"."\n";
      
//@mail("webmaster@".$domaine_ovh,"[ ERREUR ] CRON Stats-OVH --> ERREUR EXECUTION","Stats OVH non ex?cut?es, erreur dans le script...");

    
}

    
// On ferme les fichiers

    
@gzclose($fdistlog);

    @
fclose($fdistosl);

    @
fclose($floc) ; 
    
    echo 
"update awstats....\n";
    
exec($commande);
    echo 
"update done\n\n";
    
}
}
?>
Il faut le mettre a jour avec ses infos personnelles puis le stocker dans cgi-bin.
Dans cgi-bin, il faut creer un fichier texte nomme lastdayupdate.txt, contenant la date de derniere mise a jour au format JJ-MM-AAAA.
Par exemple, le 31-08-2006.

Avant d'initialiser les stats d'awstats, penser à supprimer les fichiers awstatsMMAAAA.www.le-site.com.txt.

Puis lancer le script dans une connexion ssh.

Celui ne marche pas si php n'est pas de version 4.4
On a remarque que si c'est php 4.2, l'open echoue.
La config de php semble etre differente.


Les fichiers de log utilises sont affiches.
Les fichiers de stats d'awstats sont crees, depuis le lendemain de la date donnée dans lastdayupdate.txt à la veille du jour meme.

Voila.

Et ca marche aussi en cron, pour mise a jour reguliere.

yanngarbage
01/12/2006, 12h46
A partir de la date de derniere mise a jour definie ds le fichier txt, je cree une liste de fichier avec un nom de la forme [site]-[date]-log.gz.
Le parametre [date] est une date valide entre la derniere mise a jour et la veille d'aujourd'hui..

Pour chaque date, je recupere le fichier de log, que je copie ds /www/stats puis j'appelle le call d'update aswtats_updateall.pl, je crois. Je ne suis pas chez moi et je ne sais plus mais j'en arrive a cet appel, c'est certain.

En fait, je n'ai fait que rajouter une couche aux codes que tu trouves au debut de la discussion, et qui permet de generer automatiquement les noms de fichiers de logs a prendre en compte.

Pour reinitialiser une base awstats, le script est ok.
Maintentant, pour marcher en delta, ie d'etre capable de mettre a jour une base existante, il se pose un probleme.
Il semble que le probleme vienne du fait que la date de derniere d'update connue par awstats, est la date de lancement du script ey non pas celle de la derniere log lue.
Un truc m'echappe encore mais j'avance dessus.

Objectif :
1. etre capable d'installer les stats a partir d'une date initiale => OK
2. etre capable de mettre a jour cette base par rapport a la date de dernier MAJ enregistre dans le fichier txt. => KO , en cours d'analyse.

Abogil
01/12/2006, 12h31
Yann,
Avec quelle commande mets-tu à jour la base et comment l'automatises-tu ?

mikro
01/12/2006, 12h04
Michel, as-tu vu la solution que je préconise au #94 de ce sujet ?
Il ne me reste plus qu'à trouver un spécialiste très aimable de PERL pour desactiver les print dans le script awstats.pl et le tour est joué.
Oui, mais je suis un peu réticent (à tort certainement) à utiliser un script PHP là ou un script perl peut être employé.

Autre chose, bizarrement, et contrairement à ce que tu précises dans ta contribution, OVH n'a eu aucun mal a mettre la procédure copie_loc_local.php dans leur crontab et elle s'execute parfaitement depuis.

Par contre la procédure update_awstats.sh semble poser quelques problèmes quand elle est déclenchée par crontab (que j'essaie de résoudre).

yanngarbage
01/12/2006, 11h59
Hello,

j'ai mis a jour mon profil.
Vous devrier pouvoir me contacter.

Le fonctionnement global de mon outil est le suivant:
Dans un fichier texte, j'enregistre la date de la derniere mise a jour.
Pour une mise a jour depuis le 2 octobre 2006 par exemple, j'indique dans ce fichier le 1 octobre 2006.
Ensuite, pour chaque jour depuis le 2 oct a la veille de la date courante, je recupere la log associe et je met a jour la base.

Ceci marche pour reinitialiser une base awstats, ou la mettre a jour sur des journées entières.
Mais ca ne fonctionne pas encore en delta...

Si vous vous voulez dorenavant tester le code, je pourrais vous le fournir ce we par mail.

Abogil
01/12/2006, 08h31
Citation Envoyé par yanngarbage
Bonsoir a tous et bravo pour ce HOWTO.

Je dois finaliser mes sources, mais j'ai ecris un script pour mettre a jour les stats depuis une date donnée.
Et ca peux aider des personnes, qu'ils me contactent.
Quand ils seront finalises, je proposerais de les rajouter a cette doc.
Comment te contacter Yann ?

Voila ce que je trouve dans ton profil :
Désolé ! L'utilisateur ne souhaite pas recevoir d'emails. Si vous souhaitez tout de même lui envoyer un email, veuillez prendre contact avec l'administrateur et il sera peut-être en mesure de vous aider.
Citation Envoyé par mikro
Or le fichier généré par copie_log_local.php5 ne contient que les données du jour et est écrasé à chaque nouvelle importation
Si je l'active manuellement en sautant une journée, les jours non traités n'apparaissent pas donc pas dans awstats.
Michel, as-tu vu la solution que je préconise au #94 de ce sujet ?
Il ne me reste plus qu'à trouver un spécialiste très aimable de PERL pour desactiver les print dans le script awstats.pl et le tour est joué.

mikro
01/12/2006, 08h08
Citation Envoyé par yanngarbage
Bonsoir a tous et bravo pour ce HOWTO.

Je dois finaliser mes sources, mais j'ai ecris un script pour mettre a jour les stats depuis une date donnée.
Et ca peux aider des personnes, qu'ils me contactent.
Quand ils seront finalises, je proposerais de les rajouter a cette doc.
Très bonne initiative,
Je me trouve aussi dans une situation intermédiaire, le fichier des logs est bien mis à jour chaque nuit mais le script update_awstats.sh n'est pas déclenché automatiquement (il y a un Pb que je ne peux identifier encore, en console il s'exécute parfaitement).

Or le fichier généré par copie_log_local.php5 ne contient que les données du jour et est écrasé à chaque nouvelle importation
Si je l'active manuellement en sautant une journée, les jours non traités n'apparaissent pas donc pas dans awstats.

J'imagine que le script que tu finalises permettra de rétablir une situation de ce type ?

Michel

yanngarbage
01/12/2006, 01h31
Bonsoir a tous et bravo pour ce HOWTO.

Je dois finaliser mes sources, mais j'ai ecris un script pour mettre a jour les stats depuis une date donnée.
Et ca peux aider des personnes, qu'ils me contactent.
Quand ils seront finalises, je proposerais de les rajouter a cette doc.

jalol
22/11/2006, 17h00
Bonjour à tous,

Hé bien je vois avec plaisir que mon tuto a l'air d'intéresser pas mal de monde ... Je viens de rattraper 2 pages de posts en retard que je n'avais pas lus...

Dans le how-to, il est précisé que ce n'est pas possible pour ce fichier php.
J'aimerai comprendre pourquoi.
J'avais posé la question à OVH et en fait ils ont effectivement bloqués des fonctions en ligne de commande, et notamment les fonctions liées aux manipulations de fichier. C'est pour cela que je suggère de passer par webcron, d'autant que webcron permet l'exécution en requête http, et permet donc de passer par php5...

mikro
21/11/2006, 14h36
Citation Envoyé par Daniel60
Moi aussi, mais Jalol n'a pas expliqué pourquoi non plus, c'est pourquoi j'ai opté pour cette solution : la réponse d'OVH à été pour moi très rapide ( < 24h)

Un script simplifié script.php s'execute en ligne de commande

#!/usr/local/bin/php -q
$domaine_ovh = 'items-si.fr'; // Votre domaine principal. Ne pas mettre les www
mail("michel.roger@".$domaine_ovh,"[ OK ] ssh-OVH --> OK","exe script en ssl OK exécutées correctement"); // Envoi d'un mail de confirmation

echo date("Y-m-d H:i:s")." : Script executé\n";
?>
et l'appel
login@ssh1:~/www/stats$ ./script.php >trace.txt
le fichier trace est bien créé et comporte les infos attendues
par contre la fonction mail n'envoi aucun message.

le Pb n'est donc pas lié à l'execution du fichier php mais aux limitations sur certaines fonctions, lesquelles?

Daniel60
21/11/2006, 14h17
Dans le how-to, il est précisé que ce n'est pas possible pour ce fichier php.
J'aimerai comprendre pourquoi.
Moi aussi, mais Jalol n'a pas expliqué pourquoi non plus, c'est pourquoi j'ai opté pour cette solution : la réponse d'OVH à été pour moi très rapide ( < 24h)

mikro
21/11/2006, 13h47
Citation Envoyé par Abogil
D'où l'utilité de mon kit. Actuellement j'ai 5 scripts activés toutes les heures.De plus je fait varier à volonté la périodicité de chacun des scripts.
C'est une idée mais phpobjsheduler ne devrait pas être necessaire et cela ne réponds pas à ma question, pourquoi ne peux t-on déclencher par crontab l'execution d'un script php et pourquoi en ligne de commande sous console, je ne suis pas capable d'executer ce script.

aucun message d'erreur.

Michel

Abogil
21/11/2006, 13h14
Citation Envoyé par mikro
De plus, je ne peux pour l'instant demander le declenchement de ces scripts par la crontab ovh, je dois attendre que les 2 thread encore ouverts soient fermés.
D'où l'utilité de mon kit. Actuellement j'ai 5 scripts activés toutes les heures.De plus je fait varier à volonté la périodicité de chacun des scripts.

mikro
21/11/2006, 13h03
Citation Envoyé par Daniel60
Quel crontab envisagez-vous d'utiliser ?
Ma réponse précédente concerne une demande de crontab pour les DEUX scripts auprès d'OVH.
Si votre script php fonctionne en http c'est suffisant.
En mutu 720 plan, je souhaiterai utiliser le crontab lié cet hébergement pour ne pas dépendre de la hot line. Dans le how-to, il est précisé que ce n'est pas possible pour ce fichier php.

J'aimerai comprendre pourquoi.

De plus, je ne peux pour l'instant demander le declenchement de ces scripts par la crontab ovh, je dois attendre que les 2 thread encore ouverts soient fermés.

Michel

Abogil
21/11/2006, 12h54
Bonjour à tous,

J'ai un peu la même problématique que Michel (mikro).

Mon but est de pouvoir maîtriser totalement la gestion des mes CRON et de remplacer par un kit purement local et en PHP :
  • Les CRON d'OVH qui sont un peu galère à mettre en place et qui ne permettent d'utiliser que des scripts CGI,
  • Les CRON de webcron : http://www.webcron.org qui sont limités à 3 dans la version gratuite,


Avec ce kit local en PHP je pourrai :
  • Statistiques : Vers 3h du matin avec le script copie_log_local.php5, Copier les logs de awstats dans un dossier du kit.
  • Statistiques : Mettre à jour les logs awstats vers 4h du matin avec le script awstats.pl,
  • Administration du site : Lancer les différents scripts PHP d'analyse des tables MySQL et déclancher automatiquement les actions qui s'imposent : envoi de mail, modifications d'états dans les tables, etc.


Les deux outils qui constituent ce kit sont :
  • phpjobscheduler
  • awstats


J'ai donc téléchargé :

Principe de fonctionnement :

J'ai placé l'appel de phpjobscheduler à la fin du script de la page d'accueil du site. De cette manière tout visiteur du site déclanche phpjobscheduler.

Pour que cette action soit transparente au visiteur, il importe que le script d'appel à phpjobscheduler, ainsi que tous les scripts appelés ne fassent pas d'écriture sur la page HTML générée pour le visiteur.

Tout fonctionne parfaitement à l'exception de la mise à jour des logs awstats vers 4h du matin avec le script : http://www.mondomaine.com/cgi-bin/aw...t&update=1, qui effectue bien les opérations de mise à jour Awstats, mais charge la page de résultats. Ce qui est for gênant pour le visiteur Lambda.

Aussi je lance un appel : Je cherche quelqu'un qui maîtrise le langage PERL pour supprimer dans le script awstats.pl tous les opérations de print.

Merci d'avance.

Daniel60
21/11/2006, 12h36
Quel crontab envisagez-vous d'utiliser ?
Ma réponse précédente concerne une demande de crontab pour les DEUX scripts auprès d'OVH.
Si votre script php fonctionne en http c'est suffisant.

mikro
21/11/2006, 12h29
Citation Envoyé par Daniel60
Vous n'avez pas à préciser le mode d'exécution dans la demande de crontab, veuillez seulement à mettre l'extension à .php car le serveur concerné n'a pas encore été upgradé en php5.
Bonjour,

J'ai bien changé l'extension

Dans le guide :
Une fois que vous êtes sûr du bon fonctionnement de votre script en mode shell,
Pour ce script PHP on fait comment, en mode shell ?

Michel

Daniel60
21/11/2006, 12h16
mais pour le faire executer par crontab, je dois bien le faire executer directement par l'interpreteur php ?
Vous n'avez pas à préciser le mode d'exécution dans la demande de crontab, veuillez seulement à mettre l'extension à .php car le serveur concerné n'a pas encore été upgradé en php5.
En considérant bien sûr que la demande est effectuée auprès d'OVH !

mikro
21/11/2006, 11h59
Citation Envoyé par Daniel60
Ce script s'execute en http normalement
Oui je sais, mais pour le faire executer par crontab, je dois bien le faire executer directement par l'interpreteur php ?

Michel

Daniel60
21/11/2006, 11h57
Ce script s'execute en http normalement

mikro
21/11/2006, 10h25
Citation Envoyé par jalol
Bonjour à tous !

Maintenant, pour que les statistiques soient en permanence à jour, il faut exécuter périodiquement les scripts http://www.votredomaine.tld/stats/copie_log_local.php5 et /home/votrelogin/cgi-bin/update_awstats.sh.
N'hésitez pas à faire des retours d'utilisation !
Bonjour

J'ai un soucis pour executer le script php en ssh (avant d'utiliser webcron je veux m'assurer que tout fonctionne)
le script semble se lancer mais aucune ecriture dans le fichier de log. le fichier est toujours daté d'hier du fait de la manip via le navigateur.

login@ssh1:~/www/stats$ ./copie_log_local.php
X-Powered-By: PHP/4.4.2
Content-type: text/html

login@ssh1:
Michel

mikro
18/11/2006, 12h05
Citation Envoyé par tzavdesign

Est-ce que quelqu'un a déjà eu ce problème, ou a une idée de comment le gérer... Je comprends qu'ils veulent qu'on réécrive le code en PHP4, mais pour quelle raison précisément ?

(je précise que le script marche très bien quand on appelle son URL).
....

David.
Pour la bonne raison que le cron est déclenché sur une autre machine que celle qui hébergent les plans et que ces machines (anciennes ?) ne sont pas au même niveau que les plans.
J'ai eu récemment un pB analogue pour déclencher par un backup sur MySQL 5.
impossible

Michel

Daniel60
18/11/2006, 11h56
Bonjour,
Il suffit de renommer le script en .php
Voilà

tzavdesign
18/11/2006, 11h53
Bonjour à tous.

Effectivement un tres bon post. Je rejoins ce qu'a dit Mikro, pas vu dans le tuto de modifier awstats_updateall.pl. Ca marche.

Par contre, nous sommes sur XXLPLAN et après avoir demandé à OVH de mettre en cron le script copie_log_local.php5, on a eu cette réponse :

"sur xxlplan y a pas de binaire php5.
Il vous faudra adapter le cron en php4 je suis désolé"

Est-ce que quelqu'un a déjà eu ce problème, ou a une idée de comment le gérer... Je comprends qu'ils veulent qu'on réécrive le code en PHP4, mais pour quelle raison précisément ?

(je précise que le script marche très bien quand on appelle son URL).

Merci pour votre aide à tous !

David.

mikro
15/11/2006, 07h47
Citation Envoyé par Daniel60
J'avais résolu le problème en modifiant $DIRCONFIG dans awstats_updateall.pl, en indiquant le répertoire '.'
Pas dans celui que j'ai téléchargé, j'ai du zappé qu'il fallait modifier le fichier
awstats_updateall.pl.
ce fichier n'est pas dans ftp://ftp2.lolart.net/lolart/awstats_config.zip.

merci

Michel


# $Revision: 1.11 $ - $Author: eldy $ - $Date: 2005/04/22 17:34:05 $


#------------------------------------------------------------------------------
# Defines
#------------------------------------------------------------------------------
my $REVISION='$Revision: 1.11 $'; $REVISION =~ /\s(.*)\s/; $REVISION=$1;
my $VERSION="1.0 (build $REVISION)";

# Default value of DIRCONFIG
my $DIRCONFIG = "/etc/awstats";

Daniel60
14/11/2006, 16h30
J'avais résolu le problème en modifiant $DIRCONFIG dans awstats_updateall.pl, en indiquant le répertoire '.'

mikro
14/11/2006, 12h18
Bonjour

J'utilise toujours sh pour executer mes script bash mais effectivement on peut s'en passer.
Ceci dit le message d'erreur est le même.

J'ai lancé directement le script perl

itemssi@ssh1:~/cgi-bin$ perl awstats_updateall.pl
----- awstats_updateall 1.0 (build 1.11) (c) Laurent Destailleur -----
awstats_updateall launches update process for all AWStats config files (except
awstats.model.conf) found in a particular directory, so you can easily setup a
cron/scheduler job. The scanned directory is by default /etc/awstats.

Usage: awstats_updateall.pl now [options]

Where options are:
-awstatsprog=pathtoawstatspl
-configdir=directorytoscan
-excludeconf=conftoexclude (Note: awstats.model.conf is always excluded)
Ce qui laisserait supposer qu'il ne scan pas les fichiers de conf du répertoire courant mais cherche sur le répertoire par defaut

d'ailleurs en précisant le répertoire dans les options
perl awstats_updateall.pl now
Error: Can't scan directory /etc/awstats.
itemssi@ssh1:~/cgi-bin$ perl awstats_updateall.pl now -configdir=.
Running '"./awstats.pl" -update -config=www.xxx.fr -configdir="."' to update config www.xxx.fr
Update for config "./awstats.www.xxx.fr.conf"
With data in log file "/home/itemssi/www/stats/apachelogs.log"...
Phase 1 : First bypass old records, searching new record...
Direct access after last parsed record (after line 635)
Jumped lines in file: 635
Found 635 already parsed records.
Parsed lines in file: 0
Found 0 dropped records,
Found 0 corrupted records,
Found 0 old records,
Found 0 new qualified records.

Running '"./awstats.pl" -update -config=www.yyy.fr -configdir="."' to update config www.yyy.fr
Update for config "./awstats.www.yyy.fr.conf"
With data in log file "/home/itemssi/www/stats/apachelogs.log"...
Phase 1 : First bypass old records, searching new record...
Direct access after last parsed record (after line 635)
Jumped lines in file: 635
Found 635 already parsed records.
Parsed lines in file: 0
Found 0 dropped records,
Found 0 corrupted records,
Found 0 old records,
Found 0 new qualified records.

itemssi@ssh1:~/cgi-bin$
Cela semble fonctionner (j'ai dèjà updaté manuellement via la mise à jour de AWStats)
Etrange que ce script sans préciser le répertoire dans les options fonctionne chez d'autres et pas pour moi ?
Ou bien n'ai-je pas la bonne version ?

Cordialement
Michel

Daniel60
14/11/2006, 08h07
itemssi@ssh1:~/cgi-bin$ sh ./update_awstats.sh
Ce sh me semble superflu

mikro
14/11/2006, 07h49
Citation Envoyé par jalol
Tout est noté dans le tuto
J'ai suivi les instructions du tuto, d'ailleurs, j'ai bien récuperé manuellement le fichier de log et la mise à jour via AWStats s'est déroulé correctement.
j'ai bien acces aux stats du jour.

Mon Pb est pour automatiser ces actions, un essai du script sh ./update_awstats.sh avant de le déclencher par cron me retourne l'erreur indiquée.

A la ligne 51, j'ai bien suivi le tuto ;-)
LogFile="/home/itemssi/www/stats/apachelogs.log"

jalol
14/11/2006, 00h29
Ligne 51 : renseignez le chemin absolu du fichier des logs (que l'on a déjà uploadé dans le répertoire www/stats/)
Tout est noté dans le tuto

mikro
13/11/2006, 21h15
Bonjour

Génial, l'idée du tuto sur ce sujet
Tout fonctionne sauf qu'avant de mettre en cron je teste les scripts et
même en ligne de commande et en bash, j'ai le message déjà cité
itemssi@ssh1:~/cgi-bin$ sh ./update_awstats.sh
Error: Can't scan directory /etc/awstats.
itemssi@ssh1:~/cgi-bin$
Que faut-til modifier ?

Merci

iphi63
06/11/2006, 19h00
C'est tout à fait normal que tu n'as que les stats d'hier. Tu as recuperé les stats de la veille. Je crois que le sujet à déjà été traiter.

Abogil
06/11/2006, 17h47
Je prie Iphi63 et jalol de bien vouloir m'excuser.
J'ai oublié de répondre. La mise à jour fonctionne bien maintenant. Mais c'est curieux, je n'ai pas les résultats d'aujourd'hui, je n'ai que les résultats d'hier.

Mon erreur était dans la ligne :
Code:
LogFile="/home/abogil/www/statsxxyy/apachelogs.log"
J'avais oublié de mettre à jour le "login".

Pour le fichier apachelogs.log l'attribut 644 suffit.

Par contre j'ai ajouté une protection d'accès dans mon dossier statsxxyy via le couple .htaccess et .htpasswd.

jalol
06/11/2006, 16h05
Le fichier apachelogs.log doit être en chmod 777. Cela vient sûrement de là.

iphi63
06/11/2006, 14h57
Dans ton .conf ligne 51 tu dois changer le nom de ton repertoire.
Et 222 pour les icones.

Abogil
06/11/2006, 14h51
Merci Jalol pour tout ton travail.

Mais j'ai cependant un petit souci. Pour des raisons de sécurité, j'ai renommé le dossier "stats" en "statsxxyy". Et lorsque je demande la mise à jour, j'obtiens le message d'erreur :
Error: Couldn't open server log file "/home/login/www/statsxxyy/apachelogs.log" : Permission denied

Setup ('./awstats.www.abogil.com.conf' file, web server or permissions) may be wrong.
Check config file, permissions and AWStats documentation (in 'docs' directory).
Pourtant, j'ai vérifié que :
  • Le fichier apachelogs.log était bien généré et mis à jour via le script copie_log_local.php5,
  • Le fichier apachelogs.log avait les droits d'accès 644,
  • Le dossier /www/statsxxyy avait les droits d'accès 755,


Je sèche lamentablement.

jalol
06/11/2006, 11h18
Arf, désolé... Le lien est de nouveau actif. En fait, je suis passé sur un serveur dédié récemment et j'avais mal refait mes DNS pour le lien.

Abogil
06/11/2006, 09h51
Bonjour Jalol,

Je suis intéressé par ta solution de récupérer les LOGS awstats. Mais je ne peux pas accéder à : ftp://ftp2.lolart.net/lolart/update_awstats.zip

Quelle est l'adresse exacte.

Merci

HistoQuiz
24/10/2006, 11h31
Merci Daniel60

Daniel60
24/10/2006, 11h24
FAQ−COM140 : HOW CAN I EXCLUDE MY IP ADDRESS (OR WHOLE SUBNET MASK) FROM STATS ?
PROBLEM:
I don't want to see my own IP address in the stats or I want to exclude counting visits from a whole subnet.
SOLUTION:
You must edit the config file to change the SkipHosts parameter.
For example, to exclude:
your own IP address 123.123.123.123, use SkipHosts="123.123.123.123" ·
the whole subnet 123.123.123.xxx, use SkipHosts="REGEX[^123\.123\.123\.]" ·
all sub hosts xxx.myintranet.com, use SkipHosts="REGEX[\.myintranet\.com$]" (This one works only if DNS lookup is
already done in your log file).
Ca doit se trouver vers la ligne 465.

HistoQuiz
24/10/2006, 11h08
Bonjour

J'ai une dernière question subsidiaire :
Est il possible d'exclure une adresse dans la prise en compte des stats.
Si oui, comment procéder ?
Merci
Cordialement
Pierre

HistoQuiz
18/10/2006, 16h40
Ok ça marche !!

Avec une bonne doc ça roule tout seul


Merci encore

jalol
18/10/2006, 13h29
Oui, cette adresse plante pour le moment car je suis en train de changer mes DNS. En attendant, tu peux utiliser cette adresse : ftp://anonymous.ftp.ovh.net/lolart/awstats_config.zip

HistoQuiz
18/10/2006, 13h02
Bonjour

Bon....je vais tout reprendre à 0

J'ai installé awasts avec des docs disparates ....l
Je vois que la doc de ce forum est claire et compréhensible et je vais donc tout reprendre !!

Je vois qu'il faut awstats_config.zip mais l'adresse ftp://ftp2.lolart.net/lolart/awstats_config.zip. plante

où puis je récupérer ce dossier ??

Merci

iphi63
18/10/2006, 12h30
LogFile="/home.10.3/histoqui/www/nom_du_rerpertoire_du_fichier_des_log/nom_du_fichier_log"

Dans le how to :
nom_du_rerpertoire_du_fichier_des_log = stats
nom_du_fichier_log = apachelogs.log

ce n'est pas dans cgi-bin, normalement, que tu as ton fichier log avec les statistiques que tu veux prendre en compte.

HistoQuiz
18/10/2006, 12h15
Bonjour *

mon chemin absolu est : /home.10.3/histoqui

LogFile="/home/histoqui/www/nom_du_rerpertoire_du_fichier_des_log/nom_du_fichier_log"

Si je comprends (mais je n'en suis pas sûr du tout je suis nul pour le cgi et apache)

je devrais mettre
LogFile="/home/histoqui/www/cgi-bin/nom_du_fichier_log"

cgi-bin est là où son mes fichiers awasts.
nom du fichier log ?? le dossier où j'ai mis la config pour les connections ??cordialement
Pierre

jalol
18/10/2006, 12h07
Si tu ne connais pas exactement ton chemin absolu, tu peux utiliser la fonction real_path() de PHP, ou bien en SSH avec la commande pwd

iphi63
18/10/2006, 11h41
Citation Envoyé par HistoQuiz
j'ai mis dans le LogFile="/usr/local/apache/logs/access_log"
Bonjour Pierre,

Si tu as suivi l'exellent How To de jalol,
le chemin absolu du fichier des logs doit être pour toi :

LogFile="/home/histoqui/www/nom_du_rerpertoire_du_fichier_des_log/nom_du_fichier_log"

HistoQuiz
18/10/2006, 11h07
Bonjour à tous

J'ai installé awstats sur mon serveur ! http://www.histoquiz-contemporain.co...in/awstats.pl?
ça marche mais j'ai l'impression que je ne reçois pas les bonnes stats on dirait que je reçois les stats d'autes domaines !! !

j'ai mis dans le LogFile="/usr/local/apache/logs/access_log"
l'erreur vient de là non ??
Que dois je changer ?
désolé, je n'y connais rien du tout dans apache er cgi

Cordialement

Pierre

jalol
30/09/2006, 14h18
Ah ! Je suis ravi de voir que tu aies pu réussir sans problème

Daniel60
30/09/2006, 12h31
Bonjour jalol

cd $HOME/cgi-bin
J'avais préféré mettre le chemin en toute lettre !

Bon, j'ai à présent tout mis en place : les scripts ont été testés et mis en crontab OVH en à peine 24h
Donc ça fonctionne impec

Merci pour tout

jalol
30/09/2006, 10h57
Bonjour à tous,

Après plusieurs discussions avec certains d'entre vous, je me suis aperçu que mon script update_awstats.sh était partiellement erroné ... J'ai fait la modification qu'il fallait pour que tout fonctionne, et notamment en CRON manuel, sans avoir à demander à OVH . J'ai remis le fichier ZIP du HOWTO à jour. Voici quand même le lien direct pour télécharger le nouveau script fonctionnel :
ftp://ftp2.lolart.net/lolart/update_awstats.zip

jalol
20/09/2006, 19h36
Peux-tu me contacter directement par mail stp : lolautruche (at) yahoo.fr

ALeX!S
20/09/2006, 14h22
Bah, une copie complète des logs à la main avec wget sur son pc, pour démarrer ... et puis le script php en cron chaque jour pour la suite.

Ca se complète, et ça permet de lancer Awstats mais avec des stats antérieures.

(Sinon, il doit en effet être possible d'utiliser wget avec la commande system() ou en .sh)

Enfin, par exemple ça m'as pris 2h pour mettre en place Awstats, avec les stats depuis début 2006.
(Install, upload des fichiers, logresolvemerge pour chaque mois, ...)

PS. Si logresolvemerge.pl ne veux pas fonctionner dans votre directive LogFile (du fichier conf) voila un script qui l'utilise pour faire 1 fichier / mois.

Code:
Structure de mes répertoires :

Code:
/
├─ cgi-bin (awstats.pl, logresolvemerge.pl, ...)
└─ logs
    ├─ logs-01-2006
    ├─ logs-02-2006
    └─ logs-01-2006
Lors de l'exécution il créé 1 fichier log par mois dans le même répertoire que le .pl, vous indiquez ce fichier log dans le .conf de votre site, vous et vous faite un update. Ensuite, incrémentation de $dir, et répétition de l'opération pour chaque mois.

Il ne reste plus qu'a remettre son conf en l'état d'origine, et ça roule pour la suite.

(Attention à la taille ... si vous uploadez un répertoire d'un mois - logs-XX-2006 - qui pèse 30Mo, le fichier unique feras lui aussi 30Mo. Mais une fois que vous avez le fichier unique, vous pouvez bazarder le répertoire provenant d'ovh)

PS 2. Vous pouvez de préférence, effectuer cette opération sur votre pc (si vous avez perl). Cela évitera de surcharger inutilement les serveurs d'ovh.

A bientot pour la suite !

iphi63
20/09/2006, 13h58
Citation Envoyé par ALeX!S
Code:
wget -r -l1 --no-parent -A *.log.gz http://NICKHANDLE-OVH:password@logs.ovh.net/domaine.tld/logs-MM-YYYY/
Je viens d'essayer, et c'est vraiment superbe en effet pour rapatrier les logs.

jalol
20/09/2006, 13h51
Merci pour ta réponse. Ceci dit, je ne sais pas si cette commande va fonctionner en utilisant PHP... Ceci dit, il serait peut-être possible de faire un script shell en utilisant wget.

Autre chose : L'un d'entre vous tente de récupérer ses logs mais je reçois en permanence ses erreurs par mail. Je pense que cette personne n'a pas bien paramétré le "copie_log_local.php5". Tout ce que j'ai comme expéditeur, c'est "dmdiffus". Si cela concerne l'un d'entre vous, merci de me le faire savoir

Pierre
20/09/2006, 12h09
Pas mal la récupération des logs, moi j'utilise httrack c'est pratique aussi...

ALeX!S
20/09/2006, 11h43
Bon, un petit coup de main car je vois que beaucoup font de la récupération de logs à la main (j'y pense même pas).

Je viens de reprendre en quelques minutes à peine, 200Mo de logs.

J'utilise la commande wget disponible sous linux, et téléchargeable ici pour les windowsiens. (Copiez l'exe dans x:\WINDOWS\system32, afin de l'utiliser ou vous voulez, quand vous voulez).

Ensuite, créez vous un répertoire de travail ( ex: x:\logs-ovh\ )

Puis vous faite "démarrer" - "Exécuter" - "cmd". Vous voilà en invite de commande dos.
Vous vous rendez dans votre répertoire ( cd x:\logs-ovh\ )

La il ne reste plus qu'a utiliser ce truc un peu barbare (mais tellement efficace)

Code:
wget -r -l1 --no-parent -A *.log.gz http://NICKHANDLE-OVH:password@logs.ovh.net/domaine.tld/logs-MM-YYYY/
Vous y mettez chaque fois le mois et l'année, ensuite enter. Il suffit d'utiliser "flèche haut" pour rappeler la commande.. On incrémente le mois de 1, et hop !!!

Il suffit de quelques minutes (ça dépend de votre vitesse de connexion) pour récupérer tout les logs disponible chez OVH.

Reste que vous êtes la avec des logs.gz, pas cool….

Si vous avez WinRAR, vous pouvez sélectionner tout les fichiers du répertoire (CTRL+A) et faire « Extraire ici », il ne reste plus qu'à uploader le tout (les .log - vous pouvez virer les gz, qui sont déjà selectionné), et traiter les fichiers...

Bon amusement.

iphi63
05/09/2006, 14h43
Oui je voulais dire par rapport au fichier "apachelogs.log". Qui lui m'a classé les données des 60 jours rappatriés avec d'abord les données du 4 septembre puis du 3, puis du 2 etc. jusqu'au 60ème jour demandé.

jalol
05/09/2006, 14h27
J'avais déjà commencé à écrire un script PHP permettant de le faire, mais comme je le disais les données sont tronquées...
Par ailleurs, tu dis ordre chronologique inverse, mais tu dis de faire 1er jour, 2ème... Pour moi c'est l'ordre chronologique normal ça

iphi63
05/09/2006, 14h21
J'ai trouvé une solution pour incorporer les données antérieurs et/ou à partir d'une certaine date :
Il faut reconstitué le fichier "apachelogs.log" dans l'ordre chronolique inverse.
Les données du premier jour des stats que l'on veut commencer au debut du fichier puis les données du second jour, du troisième etc.

  • 01062006
    02062006
    03062006
    04062006

    au lieu de

    04062006
    03062006
    02062006
    01062006


Je l'ai fait "manuellement" (copié/collé puis transfert), resterait à faire un fichier qui le fasse dynamiquement pour ceux qui veulent reprendre les stats existantes.

Avant de refaire les stats, il faut bien sur supprimer dans le dossier cgi-bin le ou les awstats062006.www.nomdedomaine.com.txt

epikto
04/09/2006, 17h15
ben toujours rien de neuf

Daniel60
04/09/2006, 17h13
Juste
my $DIRCONFIG = ".";

epikto
04/09/2006, 17h05
Daniel60> tu as remplacé les 4 lignes par '.' ou juste la première?

Shadow aok
04/09/2006, 16h56
Heu ...

1) Je n'ai jamais parlé d'intégrer ça (et de toute façon je ne peux pas, je suis obligé de faire un lien vers celui d'ovh, n'ayant pas les données)
2) J'ai juste répondu à un message, je ne sais pas d'origine ce qu'il fait dans cette discussion
3) Sujet clos vu qu'on est hors-sujet apparamment

Daniel60
04/09/2006, 16h40
Par que Shadow aok va integrer Awstats dans Son Script SAP
Alors il serait bien qu'il crée son thread pour cet événement

iphi63
04/09/2006, 16h36
Daniel60 écrivait :
Quel rapport avec les AWstats ?
Par que Shadow aok va integrer Awstats dans Son Script SAP :: Panel d'administration

Daniel60
04/09/2006, 16h33
En effet en 2 langues, mais l'anglais est dominant et premier, il m'a donc "agréssé" et j'ai pas vu le français...
Quel rapport avec les AWstats ?

iphi63
04/09/2006, 16h32
Shadow aok écrivait :
Oui mais l'anglais sera toujours la langue principale du site.
A terme, le script sera disponible en français/anglais/allemand/espagnol/polonais, à savoir les langues du managerV3 donc seul l'anglais me permet d'être lisible par tous.
Je comprends et concois bien qu'il faut faire ainsi, au niveau du site, c'est à moi de m'adapter et/ou d'apprendre, c'est bien en projet depuis longtemps d'apprendre l'anglais, mais plus facile à dire qu'à faire.

Shadow aok
04/09/2006, 16h26
iphi63 écrivait :
En effet en 2 langues, mais l'anglais est dominant et premier, il m'a donc "agréssé" et j'ai pas vu le français...

Donc faut attendre la version 2 pour éventuellement gagner du temps...
Oui mais l'anglais sera toujours la langue principale du site.
A terme, le script sera disponible en français/anglais/allemand/espagnol/polonais, à savoir les langues du managerV3 donc seul l'anglais me permet d'être lisible par tous.

Daniel60
04/09/2006, 16h22
No AWStats config file found in etc/awstats
J'ai aussi remplacé par '.' (voir plus haut dans ce thread), et ça marche

Daniel60
04/09/2006, 16h19
En revanche, impossible de l'importer dans awstats ... ce jour là reste vide, même avec le fichier txt du mois supprimé
Avez-vous vérifié que c'est le bon jour qui à été récupéré ?

epikto
04/09/2006, 15h44
Bon, au final, voici ce que j'ai fait et qui a marché!

- Supprimer le fichier apachelogs.log situé dans /stats
- télécharger chaque fichier de stats (1 par jour )
- uploader celui du 1er jour du mois sur le serveur à l'emplacement du fichier apachelogs.log et le renommer en apachelogs.log
- faire une sauvegarde du fichier awstatsmoisannée.votredomaine.tld.txt correspondant au mois à reconstruire
- Aller à l'url de consultation de vos stats (en théorie http://www.votredomaine.com/cgi-bin/awstats.pl si vous avez suivi ce tuto) et cliquer sur "mettre à jour"
- Répéter l'opération pour chaque journée du mois écoulée ...


Par ailleurs, quelqu'un peut-il me donner le détail de son fichier updateall, car en ssh j'ai une belle erreur: No AWStats config file found in etc/awstats
J'ai modifié le chemin en rempalçant avec un simple ., en laissant vide, ... rien ....

epikto
04/09/2006, 15h27
perso j'ai essayé avec mktime(-2) et 1 jour en historique et j'ai bien résupéré un fichier log ... datant de j-2 et seulement de j-2, donc OK

En revanche, impossible de l'importer dans awstats ... ce jour là reste vide, même avec le fichier txt du mois supprimé

iphi63
04/09/2006, 15h13
Shadow aok écrivait :
(le site est quand même dans les deux langues hein)

Sinon la v1 est quand même bugguée (pas facile à tester avec uniquement un 1000gp à l'époque et puis le manager évolue et les fonctions aussi).
En effet en 2 langues, mais l'anglais est dominant et premier, il m'a donc "agréssé" et j'ai pas vu le français...

Donc faut attendre la version 2 pour éventuellement gagner du temps...

Daniel60
04/09/2006, 15h03
En tout cas mktime(-2) n'a pas fonctionné !

Shadow aok
04/09/2006, 14h54
iphi63 écrivait :
En français super !
(Vu qur ton site est en anglais je pensais que le script ausssi).

Je vais voir ce que cela donne, quand j'aurais réussit à me dépetrer d'Awstats, c'est pas gagné.
En fait non
Mais tout le monde pense ça ^^

(le site est quand même dans les deux langues hein)

Sinon la v1 est quand même bugguée (pas facile à tester avec uniquement un 1000gp à l'époque et puis le manager évolue et les fonctions aussi).

jalol
04/09/2006, 14h43
Daniel60 écrivait :
Il y a, me semble-t-il, une erreur de syntaxe dans copie_stat_local : mktime devrait s'écrire mktime(,,,,date("d")-1,date("y")) ou quelque chose d'approchant, mais je n'ai pas encore testé.
J'ai donc mis le nom de fichier en dur pour les deux premiers jours du mois. Puis à chaque fois un petit tour de Putty !
mktime() peut très bien fonctionner avec -1 en paramètre. Cela te donne le timestamp exactement 1 jour avant le timestamp du jour

Sinon, j'ai essayé de récupérer des logs avec l'outil logresolvemerge.pl et cela fonctionne, mais il semble que j'ai des stats tronquées... Il faut que je fasse plus d'essais pour voir d'où ça vient

iphi63
04/09/2006, 14h29
En français super !
(Vu qur ton site est en anglais je pensais que le script ausssi).

Je vais voir ce que cela donne, quand j'aurais réussit à me dépetrer d'Awstats, c'est pas gagné.

Shadow aok
04/09/2006, 14h25
iphi63 écrivait :
Oui c'est juste, je pensais, email visible, aussi, bref je passe par son site.

Ton SAP Shadow aok, est aussi en version française ou qu'en anglais ?
La V1 n'existe qu'en français mais la V2 (en cours de dev) sera multilangue et livrée avec au moins le français et l'anglais.

Daniel60
04/09/2006, 14h18
Il y a, me semble-t-il, une erreur de syntaxe dans copie_stat_local : mktime devrait s'écrire mktime(,,,,date("d")-1,date("y")) ou quelque chose d'approchant, mais je n'ai pas encore testé.
J'ai donc mis le nom de fichier en dur pour les deux premiers jours du mois. Puis à chaque fois un petit tour de Putty !

epikto
04/09/2006, 14h01
peux-tu décrire ta manip pour le refaire jour par jour, car j'ai beau essayer, j'ai pas réussi!

j'ai craché le fichier de septembre et mis le log du 1er sept, mais il n'a pas voulu le prendre: après actualisation, septembre reste vierge

Daniel60
04/09/2006, 13h46
La galère !
J'ai été obligé de supprimer septembre et de refaire chaque jour succcessivement. Il doit y avoir une instruction à passer pour indiquer le jour à traiter...

iphi63
04/09/2006, 12h42
Manuel OK, c'est ce que je fait puisque j'ai pas fait encore la "version automatique".
Mais le problème est : qu'on arrive pas à integrer les stats anterieur de la veille, en tout cas pour moi. Il me semble que je ne suis pas seul dans le même cas.

J'ai récupéré les stats des 2 derniers jours, mais comment faut faire pour que Awstats integre les 2 journées ? il ne prend que la dernière !?

jalol
04/09/2006, 12h34
C'est bon, les serveurs de logs sont réparés, il suffit de faire une mise à jour manuelle (copie_log_local.php5 et awstats)

iphi63
04/09/2006, 12h25
Oui c'est juste, je pensais, email visible, aussi, bref je passe par son site.

Ton SAP Shadow aok, est aussi en version française ou qu'en anglais ?

jalol
04/09/2006, 12h25
Envoie-moi un mail à lolautruche(at)yahoo.fr

Sinon, il faut attendre que les serveurs de logs soient réparés...

Shadow aok
04/09/2006, 12h06
Les messages privés ne sont pas activés sur le forum

iphi63
04/09/2006, 12h01
C'est bien ce que je redoutais, on fait comment ? On à l'air malin envers les personnes qui comptes sur leurs stats !?

Jalol envois moi un message en privé STP, j'ai quelque chose à t'écrire, car toi tu ne les acceptes pas les messages.

jalol
04/09/2006, 11h55
Hier le serveur web des logs OVH a crashé. Ils sont en train de réparer tout ça

iphi63
04/09/2006, 11h52
Vous avez réussit à faire vos mise à jour stats, hier dimanche 3 septembre ?
Car moi non ? Aujourd'hui oui et samedi aussi ???

Daniel60
01/09/2006, 17h43
l faudrait que j'aille faire un tour dans la doc de Awstats, car il doit y avoir un truc pour qu'il prenne en compte tous les logs...
Il y a ça dans les FAQ :

FAQ−COM360 : HOW CAN I PROCESS SEVERAL LOG FILES IN ONE RUN ?
PROBLEM:
How can I update my statistics for several log file, in one run ?
SOLUTION:
A solution should be to setup your config file with something like:
LogFile=mylog*.log
However, with such a syntax, AWStats can't know in wich order processing log files (wich log file is the first, next or last).
So to work like this you must use the following syntax:
LogFile="/pathto/logresolvemerge.pl mylog*.log |"
Logresolvemerge is a tool provided with AWStats (in tools directory) that merge several log files on the fly. It opens pointer
on each files and sends, line by line, the oldest record from this. Using such a tool as a pipe source for AWStats LogFile
parameter is a very good solution because, it allows you to merge log files whatever their size with no memory use, no
hard disk use (no temporary files built), it is fast, it prevents you from a bad order if your log files are not correctly ordered,
etc...
This tool can also be used to process log files from load balanced systems (see FAQ−COM400)

Cordialement

jalol
01/09/2006, 14h34
Il faudrait que j'aille faire un tour dans la doc de Awstats, car il doit y avoir un truc pour qu'il prenne en compte tous les logs...

Sinon, pour la vue annuelle, c'est normal car je ne l'avais pas autorisée via l'interface web. Pour l'autoriser, il faut modifier le fichier awstats.www.votredomaine.tld.conf à la ligne 258 pour mettre AllowFullYearView=3.

Je modifie le HOWTO pour ça

iphi63
01/09/2006, 11h37
Bonjour Jalol,

Félicitation pour ce travail.

Reste à comprendre la récupération des données annciennes et son traitement, ce n'est pas clair.

Je ne sais si il ya un rapport, mais J'ai constaté cela quand je suis allé voir tes stats, et choisis comme période d'analyse : l'année. Et on a :

Error: Full year view has not been allowed from a browser (AllowFullYearView should be set to 3).

Setup ('./awstats.www.lolart.net.conf' file, web server or permissions) may be wrong.
Check config file, permissions and AWStats documentation (in 'docs' directory)

jalol
01/09/2006, 00h23
Je pense qu'il doit être possible de configurer AWstats pour qu'il prenne aussi les logs plus anciens. Dans le fichier conf, il est dit que awstats sait automatiquement renconnaître les nouveaux logs des anciens s'ils sont dans un seul fichier. Je pense qu'il doit se fier à la date, mais je n'ai pas trouvé où changer cela pour qu'il prenne en compte plusieurs jours avant.

Sinon, tu peux toujours tout te taper à la main, jour par jour en modifiant le fichier PHP à chaque fois...

epikto
31/08/2006, 18h18
en effet.

j'ai lancé ton fichier, il importe bien dans le fichier log, mais ne les intègre pas dasn awstats ... zarbi

jalol
31/08/2006, 11h29
Bon, j'ai fait divers essais, mais je n'ai pas trouvé de solution.
J'ai essayé de modifier le script copie_log_local.php5 pour récupérer les logs plusieurs jours en arrière, jusqu'ici pas de pb, mais awstats ne semble prendre que le premier jour qu'il trouve ...
Je donne quand même le copie_log_local.php5 modifié : ftp://ftp2.lolart.net/lolart/copie_l...al_anciens.zip

Tu paramètres le nombre de jours antérieurs à récupérer en changeant la variable $nbjours. Attention, c'est assez long et en plus le fichier log résultant est particulièrement volumineux (chez moi 32 Mo pour 3 jours de log ! )

epikto
31/08/2006, 09h43
heu .... LOL depuis la création de mon plan ... mais rassure-toi il ne date que de 2 semaines

Une idée sur la méthode?

jalol
31/08/2006, 09h33
Pour ça il faudrait modifier le fichier copie_log_local.php5 et le configurer pour récupérer les logs antérieurs... Tu voudrais récupérer quoi? Un mois ou depuis la création de ton plan? lol

epikto
31/08/2006, 09h31
Yep, mais il y a récemment eu des prbl avec webcron.

Donc bon, au final j'ai coupé la poire en deux, comme tu le suggère: SSH et Webcron.

Une idée sinon pour récupérer les logs antérieurs à J-1 pour reconstituer l'historique le plus complet possible?

jalol
31/08/2006, 09h21
Mais il n'y a pas de quoi . Il est normal de faire partager ses expériences... En ce qui concerne le CRON avec les fichiers PHP, ce n'est pas que cela ne fonctionne pas, car l'exécution de php en ligne de commande marche très bien, mais avec des restrictions, et notamment sur les fichiers. En fait, il est impossible de récupérer les logs depuis la ligne de commande. J'ai trouvé ça bizarre aussi, mais bon, la hotline m'a répondu que c'était une question de sécurité donc je ne discute pas même si je trouve ça dommage.

Ceci dit, si tu veux être entièrement autonome, tu peux toujours utiliser Webcron

epikto
31/08/2006, 08h32
Merci pour ce superbe tuto!
j'ai réussi du premier coup !!
reste un truc qui est dommage: pourquoi OVHY n'autorise pas d'executer le script en php en cron ... ça simplifierait les choses et permettrait une grande autonomie (trop sans doute avec des risques de sécu?)

Bref, merci encore!

jalol
30/08/2006, 10h14
Hello
Cette procédure bash m'a l'air compliquée à mettre en oeuvre...
Effectivement, cela peut effrayer, mais il n'y a rien de sorcier... En fait, le problème vient du fait que l'appel de la ligne de commande awstats_update.pl now ne fonctionne pas si on l'appelle depuis la fonction shell_exec() de PHP... Du coup, on est obligé de passer par SSH pour la config

Effectivement, j'ai dû oublier de dire qu'il fallait transférer le dossier /icon dans www/stats, dsl, je mets à jour le HOWTO.

Je viens de mettre à jour l'archive du HOWTO, les logs sont donc maintenant triés par date. Cela dit, je n'avais pas de problème de logs corrompus, mais on ne sait jamais...

J'ai également mis à jour le HOWTO pour simplifier la procédure de première mise à jour via l'interface web de Awstats, moins austère que la ligne de commande en SSH .

Daniel60
30/08/2006, 09h59
Bonjour,
Cette procédure bash m'a l'air compliquée à mettre en oeuvre...
J'avais résolu le problème en modifiant $DIRCONFIG dans awstats_updateall.pl, en indiquant le répertoire '.' .
Mais si le job est indiqué 'running' , la mise à jour ne se fait pas

J'ai remarqué aussi qu'il fallait tranférer le répertoire /icon/ dans www/stats/ pour avoir une meilleure présentation.

Enfin je confirme qu'il faut bien trier les logs par heure sinon le résultat est tronqué.

Voici une version de copie_log_local.php modifiée, inpirée de Kerfred :


Code PHP:
#!/usr/local/bin/php#!/usr/local/bin/php
$domaine_ovh   'mondomaine.com'// Votre domaine principal. Ne pas mettre les www
$nichandle_ovh 'monhandle'// Votre Nic-Handle OVH
$pass_ovh      'monpass'// Votre mot de passe OVH (celui qui vous permet d'aller à l'admin OVH
$log_local     'apachelogs.log'// Le nom du fichier local qui contiendra le dernier log à jour. C'est le nom de ce fichier qu'il faut renseigner dans le fichier conf de AWStats awstats.votresite.com.conf

$log strftime($domaine_ovh."-%d-%m-%Y.log",mktime(-1)); // Nom du log de la veille (mktime(-1) pour le jour précédent)
$replog strftime("logs-%m-%Y",mktime(-1)); // Répertoire du mois en cours
$reposl "osl";

// Les adresses pour récupérer les logs bruts à jour
// Ces adresses sont sous la forme [url]http://votrenichandle:votrepass@logs.ovh.net/votredomaine.com/repertoire/fichier_log[/url]
$urllog "http://".$nichandle_ovh.':'.$pass_ovh."@logs.ovh.net/".$domaine_ovh."/".$replog."/".$log.'.gz';
$urlosl "http://".$nichandle_ovh.':'.$pass_ovh."@logs.ovh.net/".$domaine_ovh."/".$reposl."/".$log;
$urlstats "./".$log_local// Le fichier log qui sera stocké en local sur le serveur

// Ouverture des fichiers logs distants. Les logs archivés sont au format gz
$fdistlog = @gzopen($urllog"r"); // Le log archivé
$fdistosl = @fopen($urlosl"r"); // Le log OSL

$error false;

if(
$fdistlog) { // Si on arrive à ouvrir le fichier archivé
  
$url  $fdistlog;
  
$type 'gz';
} elseif(
$fdistosl) { // Si on arrive à ouvrir le fichier OSL
  
$url  $fdistosl;
  
$type 'f';
} else 
$error true// On arrive à ouvrir aucun des 2 fichiers

if(!$error) { // S'il n'y a pas d'erreur, on parcourt le fichier
  
$i=0;
  
$tabligne=array();
  if (
$type == 'gz') { // On travaille sur l'archive, il faut donc utiliser gz
    
while (!gzeof($url)) {
      
$ligne = @gzgets($url2048);
      list(
$IP$host$user$date$other)=split(" "$ligne);
      
$tabligne[$date.':'.sprintf("%05d"$i)]=$ligne;
      
$i++;
    }
  } 
  elseif (
$type == 'f') { // On travaille sur le fichier OSL
    
while (!feof($url)) {
      
$ligne = @fgets($url,2048) ;
      list(
$IP$host$user$date$other)=split(" "$ligne);
      
$tabligne[$date.':'.sprintf("%05d"$i)]=$ligne;
      
$i++;
    }
  }
  
ksort($tabligne) ;
  
$floc = @fopen($log_local,"w+") ;
  foreach(
$tabligne as $ligne) {// On écrit la totalité du log dans le fichier log local
    
fputs($floc,$ligne) ;
  }
  @
mail("postmaster@".$domaine_ovh,"[ OK ] CRON Stats-OVH --> OK","Stats OVH OK exécutées correctement"); // Envoi d'un mail de confirmation
}
else { 
// Erreur, on n'a pas réussi à ouvrir un seul fichier log distant
  
@mail("postmaster@".$domaine_ovh,"[ ERREUR ] CRON Stats-OVH --> ERREUR EXECUTION","Stats OVH non exécutées, erreur dans le script...");
}
// On ferme les fichiers
@gzclose($fdistlog);
@
fclose($fdistosl);
@
fclose($floc) ;
?>
Bonne journée !

jalol
29/08/2006, 10h10
Désolé d'avoir mis du temps à répondre .
Je viens de mettre à jour le HOWTO. En fait, il se trouve que les commandes Shell ne fonctionnent pas bien en appel depuis PHP. J'ai donc fait un script Shell (update_awstats.sh) à la place du script PHP.

Daniel60
26/08/2006, 22h39
Tout d'abord un grand merci pour le travail accompli.

J'ai scrupuleusement suivi la procédure mais j'obtiens ce message d'erreur à l'exécution de update_awstats.php5 :

Error: Can't scan directory /etc/awstats.

Il faut signaler par ailleurs que ce même fichier doit aussi être édité avec le chemin absolu.

D'autre part je pense qu'il faudrait inclure un tri par heure, cf

Cordialement

jalol
19/08/2006, 01h08
Bonjour à tous !

Les offres PLAN permettent d'héberger plusieurs domaines, et donc plusieurs sites, sur votre hébergement principal.
Comme beaucoup, je me suis demandé si je pouvais avoir des statistiques distinctes pour chacun des sites que j'héberge, et si possible avec AWStats (très complet). Par défaut, les statistiques proposées par OVH ne concernent que le domaine principal et tout ce qui est hébergé dessus.

J'ai donc longuement épluché ce thread pour trouver une solution à mon problème : http://forum.ovh.com/showthread.php?...9&pagenumber=1.
Cependant, il a fallu que je compile toutes les informations données ici pour réussir à faire ce que je voulais, à savoir pouvoir consulter les statistiques de chacun de mes domaines hébergés sur mon compte OVH 90Plan (option multi-domaine).

Vous trouverez ci-dessous la marche à suivre :


D'abord, téléchargez et décompressez les fichiers de configuration que je vais utiliser dans ce HOWTO : ftp://ftp2.lolart.net/lolart/awstats_config.zip.

  • Dans votre dossier www, créez un dossier "stats" en chmod 755.
  • Dans ce dossier "stats", uploadez le fichier apachelogs.log contenu dans l'archive.


Téléchargez également la dernière distribution de AWStats (la 6.5 à l'heure de l'écriture de ce HOWTO). Décompressez-la. Vous obtiendrez 3 répertoires : docs, wwwroot et tools.

  • A l'intérieur du dossier wwwroot, dans le dossier cgi-bin, copiez le fichier awstats.www.votresite.com.conf (contenu dans l'archive awstats_config.zip).
  • Nommez le en fonction de votre domaine (ex. toto.com => awstats.www.toto.com.conf).
  • Ouvrez le avec un éditeur texte
  • Ligne 51 : renseignez le chemin absolu du fichier des logs (que l'on a déjà uploadé dans le répertoire www/stats/)
  • Ligne 153 : renseignez le domaine dont vous voulez visualiser les statistiques (ex. => SiteDomain="www.toto.com")
  • Ligne 168 : renseignez les alias que pourraient taper les visiteurs de ce site (ex. => HostAliases="www.toto.com toto.com sousdomaine.toto.com". Bien sûr, sousdomaine.toto.com n'est utile que si vous avez un sous-domaine nommé ainsi )
  • Ligne 258 : Mettez la valeur de AllowFullYearView à 3 si vous voulez consulter les stats annuelles
  • Pour chacun des domaines que vous hébergez, faites un fichier conf séparé nommé de la même manière (ex. awstats.www.toto2.com.conf et les lignes 153 et 168 correctement adaptées à chaque domaine)
  • Editez le fichier update_awstats.sh de l'archive awstats_config.zip, dans répertoire cgi-bin en y mettant le chemin absolu qui correspond à votre domaine, du type /home.5/login/. Pour le connaître, utilisez la fonction PHP realpath() ou connectez-vous en SSH et tapez la commande pwd . Ne remplacez que /home/login avec vos valeurs.
  • Uploadez la totalité du contenu du répertoire cgi-bin ainsi que le fichier update_awstats.sh de l'archive awstats_config.zip dans le dossier cgi-bin de votre serveur. Uploadez également le contenu du dossier wwwroot (sauf le dossier cgi-bin bien sûr ) dans votre répertoire www/stats
  • Sur votre serveur, dans le dossier cgi-bin (une fois que tout est uploadé), mettez des droits d'accès 755 pour tous les fichier *.pl et au fichier .sh


Voilà, à priori notre installation de AWStats est configurée. Nous allons maintenant récupérer les derniers logs via notre script PHP copie_log_local.php5

  • Ouvrez le fichier copie_log_local.php5 avec un éditeur texte et éditez les premières lignes avec votre domaine, votre nic-handle et votre mot de passe, tout ça entre les guillemets.
  • Sauvegardez ce fichier et uploadez-le dans votre dossier www/stats/
  • Une fois uploadé, ouvrez votre navigateur et exécutez-le à l'adresse http://www.votredomaine.com/stats/copie_log_local.php5 . Cela aura pour effet de copier tous les logs du jour précédent dans le fichier www/stats/apachelogs.log et de vous envoyer un mail sur postmaster@votredomaine.com pour vous dire si la copie des logs s'est bien déroulée


EDIT 31-12-2006 (Merci à Shun pour sa contribution )
Vous pouvez également récupérer d'anciens logs grâce au script copie_log_local_full.php5. Mettez le script PHP copie_log_local_full.php5 ainsi que le fichier apachelogsfull.log dans le répertoire www/stats/ que nous avons créé et allez exécuter le script en mettant en paramètre le nombre de jours que vous voulez récupérer. Par ex. : http://www.votresite.tld/stats/copie...l.php5?jour=30 . => Ici on récupère les stats depuis 30 jours

NB : Si vous avez déjà compilé des statistiques pour un mois donné et qu'il vous manque celles du début du mois, effacer les fichiers awstats*.txt dans cgi-bin avant de relancer update_awstats.sh

Reste maintenant à mettre à jour AWStats pour prendre en compte les logs que nous venons de mettre à jour
  • Dans le répertoire d'AWStats (sur votre disque dur), dans le dossier tools, vous avez un fichier awstats_updateall.pl. Uploadez-le dans votre répertoire cgi-bin et mettez le en chmod 755.
  • Vérifiez que vous avez bien uploadé le fichier update_awstats.sh en chmod 755 dans le répertoire cgi-bin
  • Rendez-vous sur l'interface web d'awstats en se rendant à l'adresse http://www.domaineprincipal.tld/cgi-...g=www.toto.com et en cliquant sur "Mettre à jour maintenant"
  • Vos statistiques sont prêtes à être utilisées ! Vous n'avez plus qu'à vous rendre à l'adresse http://www.votredomaineprincipal.tld...g=www.toto.com pour consulter les stats du site toto.com !
  • Pour consulter les stats de votre domaine principal, tapez simplement l'adresse http://www.votredomaineprincipal.tld/cgi-bin/awstats.pl . La procédure est la même pour mettre à jour.



Maintenant, pour que les statistiques soient en permanence à jour, il faut exécuter périodiquement les scripts http://www.votredomaine.tld/stats/copie_log_local.php5 et /home/votrelogin/cgi-bin/update_awstats.sh. Pour cela, vous pouvez soit demander à OVH de mettre ces scripts en CRON (par l'interface de contact de votre domaine (le plus simple), soit passer par Webcron et SSH (ce que je recommande si vous voulez avoir les mains libre, mais nécessite une manipulation par SSH en ligne de commande). Webcron est un service gratuit permettant d'exécuter périodiquement vous scripts. Ouvrez-vous un compte puis ajoutez vos tâches très simplement.


VOUS ETES DEBUTANTS, SSH VOUS FAIT PEUR

Demandez à OVH l'ajout de vos scripts à la crontab. Il est mieux de leur donner l'adresse absolue de vos scripts, à savoir sous le format /home/votrelogin/www/stats/copie_log_local.php5 et /home/votrelogin/cgi-bin/update_awstats.sh. Vérifiez d'abord si ces scripts fonctionnent via l'interface web pour le fichier php5 (http://www.domaineprincipal.tld/stat...log_local.php5) et via SSH pour le fichier .sh .
Précision supplémentaire, si vous souhaitez connaître l'adresse exacte de votre chemin absolue, connectez-vous en SSH avec Putty (Guide Putty) et tapez la commande pwd
Autre chose, demandez d'exécuter d'abord copie_log_local.php5 et ensuite update_awstats.sh, et ce à au moins une heure d'intervalle, et de préférence la nuit, par exemple à 2h00 et 3h00 du matin


UTILISATEURS AVANCES
Si vous préférez gérer vous-même la crontab, sachez qu'en mutualisé c'est possible, mais avec certaines restrictions qui vous empêchent de récupérer les logs avec le script PHP. Il faudra donc éditer la crontab pour lancer périodiquement le script .sh et utiliser webcron pour la récupération des logs.
Pour la suite, je vous suggère vivement de consulter le guide OVH sur la crontab.
Connectez-vous en SSH et tapez
Code PHP:
crontab -
pour éditer la crontab et y ajouter le script /home/votrelogin/cgi-bin/update_awstats.sh à l'heure que vous souhaitez (de préférence la nuit).
Exemple :
Code PHP:
05 3 * * * /home.10/votrelogin/cgi-bin/update_awstats.sh 
pour une exécution tous les jours à 03h05 du matin

N'oubliez pas d'exécuter régulièrement le script PHP de récupération des logs (http://www.domaineprincipal.tld/stat...log_local.php5) par Webcron, A UNE HEURE ANTERIEURE de l'heure d'exécution du script update_awstats.sh (une heure avant, c'est bien ).
Note : J'ai remarqué que l'exécution du script copie_log_local.php5 posait problème avant 2h00 du matin. Faites le donc vers 2h...


J'espère que ce HOWTO pourra aider... N'hésitez pas à faire des retours d'utilisation !