Another Home Page Blog - Perl

CentOS 7 : installation vraiment minimale - errata

2018-04-23T09:30:00+02:00

Dans un billet précédent, j'avais réalisé une installation vraiment minimale de CentOS 7. Si globalement le cahier des charges était respecté, je me suis heurté à quelques petites déconvenues, je me suis donc dit qu'un billet sous forme d'errata ne serait pas de trop.

SELinux

Bon, d'accord, SELinux est probablement l'un des composants de CentOS, Fedora et RHEL le plus détesté (ou est-ce systemd ?), car nombreux sont encore les tutoriaux qui commencent par demander de désactiver celui-ci (à tort). Bref, si comme moi vous vous attendez à ce que votre système minimaliste soit paramétré en "Enforcing" (après tout c'est marqué dans le kickstart), pas de chance. Tapez 20 fois la commande setenforce Enforcing si vous voulez, la réponse sera la même : non.

Pourquoi ? Parce que votre serviteur, en allant tailler dans les paquets à la tronçonneuse, s'est débarrassé des politiques SELinux. Sans politique, cela fonctionne moins bien. Comment on les obtient ? En installant deux paquets : selinux-policy et selinux-policy-targeted. N'envisagez pas un seul instant de n'installer que le premier : le système se bloquera au démarrage.

scp

Quand on est sur une machine serveur, il n'est a priori pas nécessaire d'installer un quelconque client, sauf cas exceptionnel et identifié. En voici un : sans installer le paquet openssh-clients sur mon serveur minimaliste, je ne peux pas faire de scp vers celui-ci. Je suppose que le binaire scp doit être appelé à un moment quelconque côté serveur, mais toujours est-il que sans, bein ça ne fonctionne pas.

Perl et la locale

Celui-ci est assez tordu et concerne les paramétrages de langue. Il se trouve qu'après avoir installé Perl sur ce serveur minimaliste, j'ai voulu lancer un script utilisant ce langage. J'ai eu droit, durant les scripts, à un message de ce genre :

perl: warning: Falling back to the standard locale ("C").

Alors le pourquoi exact, je ne suis toujours pas certain, je suspecte qu'il manque un paquet et que celui-ci (toujours pas identifié) fait un paramétrage particulier, toujours est-il que je me voyais mal modifier ma configuration OpenSSH pour aller jouer avec les variables d'environnement exportées par ce dernier. J'ai préféré finalement ajouter deux petites lignes à /etc/environment :

LANG=en_US.utf-8
LC_ALL=en_US.utf-8

Cela force le système en anglais américain, en UTF-8.

Les logs

Bon alors celle-là, elle est fantastique : rsyslog n'est du coup plus installé par défaut et certains logiciels n'envoient plus de log, comme OpenSSH : j'ai voulu diagnostiquer des erreurs de connexion SSH et je n'avais pas de fichier /var/log/secure ! En effet, par défaut OpenSSH sous CentOS utilise le protocole syslog pour fournir ses logs. A noter aussi que logrotate manquait, ce qui aurait pu s'avérer plus dramatique au bout de quelques mois sur une machine de production.

C'est tout ?

Ce n'est probablement que le début. Je me rends compte à l'usage qu'il me manque pas mal de choses de mon petit confort (vim, less, tmux...). Un autre paquet que je n'ai pas encore réinstallé est NetworkManager, à voir si cela devient vraiment pratique.

Vous avez aimé cet article ? Alors partagez-le sur les réseaux sociaux !

Crédit photo : Adam Sherez - Same but different.

Commentaires

Le 15/06/2018 06:47 par Alain C

Merci pour ton tuto ! Perso je me verrais mal bosser sans NetworkManager mais je pense que c'est facile à ré-installer une fois que CentOS 7 est ON ? Non ? Au plaisir, Alain

Le 16/06/2018 12:12 par Nils

Merci de ton commentaire Alain ! Pour ce qui est de l’installation de NetworkManager sur un système CentOS 7 existant, oui c’est facile, il suffit d’utiliser yum pour les packages ! En revanche si de nombreuses configurations réseau particulières ont été faites (bridge, bonding...) ça sera un peu plus coton.

Personnellement j’ai connu les versions précédentes de CentOS et de Fedora, où NetworkManager n’était pas forcément présent, donc je n’aurais pas de problème sans ;)

Le 20/06/2018 06:33 par Alain C

Ok super ! Merci pour ta réponse je vais essayer :)

Ajouter des robots dans Awstats

2011-11-21T09:30:00+01:00

Aujourd'hui un nouvel épisode de mon outil de statistiques web du moment, Awstats. Souvenez-vous, nous avons déjà rencontré ce logiciel à trois reprises :

lors d'un premier billet d'introduction et de configuration ;
pour activer des plugins afin d'améliorer les statistiques ;
mais aussi lors de l'ajout de sections personnalisées spécifiques à votre site internet.

Aujourd’hui attardons-nous sur une autre possibilité d'Awstats : la détection des robots et moteurs de recherches. Si vous avez déjà des statistiques en place, vous aurez noté que vous disposez d'une rubrique “Visiteurs Robots/Spiders” dans votre page. Awstats ne peut pas connaître tous les robots sur le marché, de nouveaux sont créés tandis que d'autres disparaissent. Certains sont dédiés à des moteurs de recherche, d'autres sont des logiciels téléchargeables, pour effectuer des recherches ou créer un aggrégateur de flux RSS. Lorsqu'Awstats repère un robot qu'il ne connait pas, il peut l'afficher de deux manières : “Unknown robot (identified by 'bot*')” ou bien “Unknown robot (identified by '*bot')”. Vous comprenez donc qu'il cherche juste le mot “bot” dans le User-agent laissé par votre visiteur dans les logs de votre serveur web.

Si vous regardez souvent les logs de votre serveur web (activité qui peut semble à première vue excentrique, mais Ô combien intéressante en réalité), vous trouverez sans doute un robot qui n'est pas connu d'Awstats. Ce billet prend l'exemple avec cplanet, un aggrégateur RSS utilisé en particulier par un certain planet BSD francophone.

Awstats stocke les noms des robots qu'il connaît dans un fichier nommé “robots.pm”. Ce fichier, dans le cas d'une installation via pkgsrc sous NetBSD se trouve à l'endroit suivant : /usr/pkg/awstats/cgi-bin/lib/robots.pm. Effectuons-donc une copie de sauvegarde de ce fichier :

root@vhost:/usr/pkg/awstats/cgi-bin/lib# cp -vp robots.pm robots.pm.bak
robots.pm -> robots.pm.bak

Profitons-en pour copier la sauvegarde dans un autre fichier, que nous allons modifier :

root@vhost:/usr/pkg/awstats/cgi-bin/lib# cp -vp robots.pm.bak robots.pm.custom
robots.pm.bak -> robots.pm.custom

Avant de modifier le fichier, jetons un oeil aux logs (Apache dans mon cas) :

1.2.3.4 - - [04/May/2011:16:30:48 +0200] "GET /feed/atom HTTP/1.1" 200 105441 "-" "cplanet/0.6"

Le User-agent de cplanet est donc : "cplanet/0.6". Maintenant éditons notre robots.pm.custom. En lisant les commentaires on se rend compte que le fichier est organisé en plusieurs listes. Il faut donc ajouter notre nouveau robot dans deux d'entres elles, RobotsSearchIDOrder_list\<X> (où \<X> désigne un chiffre) et RobotsHashIDLib. J'ai choisi d'ajouter mon robot dans RobotsSearchIDOrder_list2, qui contient des robots peu connus. Je suis allé à la fin de cette liste mais je n'ai pas ajouté mon robot en toute fin de liste mais juste après un robot nommé “zeus”. Pourquoi ? Il s'avère que certains noms de robots sont des expressions régulières, et doivent être en fin ou en début de liste. Donc je ne souhaite pas les perturber.

Voici les lignes contenant “zeus” et cplanet (aux alentours de la ligne 965) :

'zeus',
'cplanet',

Passons à la deuxième liste, qui commence aux alentours de la ligne 1000. Vers la ligne 1320, on peut lire le commentaire suivant : “Other robots reported by users”. Je suis donc à nouveau descendu jusqu'à retrouver “zeus” et j'ai ajouté de cette manière cplanet, juste en-dessous :

'cplanet','<a href="http://git.etoilebsd.net/cplanet/" title="A rss feed agregator that generate static html pages" target="_blank">CPlanet RSS agregator</a>',

J'ai donc créé un identifiant pour mon robot, qui est en fait une chaîne de caractères basée sur le User-agent, et ai ajouté un lien vers l'URL du robot pour savoir d'où il vient, ainsi qu'un texte descriptif, en anglais. Notez bien le format de séparation, et que la virgule à la fin est obligatoire.

Maintenant que notre fichier personnalisé est prêt, reste à le mettre en production :

root@vhost:/usr/pkg/awstats/cgi-bin/lib# rm -vf robots.pm && ln -sv robots.pm.custom robots.pm
robots.pm
robots.pm -> robots.pm.custom

Si jamais Awstats doit être mis à jour, celui-ci écrasera le lien symbolique. Il faudra donc vérifier (avec la commande diff par exemple) si le projet Awstats a mis à jour de son côté le fichier, et reporter nos modifications dans une copie du nouveau. Pensez d'ailleurs à proposer vos nouveaux robots sur le bug tracker d'Awstats sur Sourceforge

Ajouter ses sections personnalisées dans Awstats

2011-02-28T09:30:00+01:00

Après la configuration de base et l'activation de plugins, amusons-nous maintenant à personnaliser nos statistiques avec les "Extra Sections". Avant toute chose, il convient de rappeler que comme certains plugins, ces ajouts ralentissent la vitesse d'exécution d'Awstats : sur des sites internet très visités, il peut s'avérer très utile d'avoir une centralisation des logs et de ne pas utiliser Awstats directement sur les serveurs web de production.

Il est possible, grâce à ces sections, d'ajouter des filtres. Pour un site marchand par exemple on peut trier les produits et lister les meilleures ventes selon les catégories. Il est aussi possible, pour un blog, de voir les hits sur les flux RSS et même de voir quel client RSS est utilisé. C'est ce que je vous propose dans la suite.

Chaque "Extra Section" s'ajoute dans Awstats à la fin du fichier de configuration. Si vous souhaitez utiliser les mêmes sections pour plusieurs fichiers de configuration, il est possible de faire de l'inclusion de fichiers. On peut par exemple créer un fichier /usr/pkg/etc/awstats/extra_sections.conf et écrire dans le fichier de configuration de notre site internet la directive :

Include "extra_sections.conf"

Cela peut s'avérer très pratique car les sections sont numérotées. La première section voit ses variables suffixées par le chiffre 1, la deuxième par le chiffre 2, ainsi de suite... Le copier-coller est donc à manier avec précaution, je n'ai jamais tenté d'avoir deux sections 1.

Détaillons à présent un premier exemple : je cherche à lister les visites sur mes flux RSS.

ExtraSectionName1="Flux RSS / Atom"
ExtraSectionCodeFilter1="200 304"
ExtraSectionCondition1="URL,^\\/feed\\/.*"
ExtraSectionFirstColumnTitle1="Nom du flux"
ExtraSectionFirstColumnValues1="URL,^\\/feed\\/([\\w]+)\\/"
ExtraSectionStatTypes1=PHK
MaxNbOfExtra1=1000
MinHitExtra1=1

Cette section filtre donc les codes HTTP 200 et 304 ayant lieu dans le répertoires /feed/. J'affiche les URLs commençant par /feed/ pour les lister et enfin, j'indique le nombre de pages et le nombre de hits (qui dans ce cas de flux RSS ont la même valeur). Je décide de limiter le nombre d'entrée à 1000 et estime le nombre minimum de hits pour apparaître dans les stats à 1. Il est possible d'adapter simplement cet exemple à d'autres URLs.

Passons au deuxième exemple :

ExtraSectionName2="Lecteurs de RSS"
ExtraSectionCodeFilter2="200 304"
ExtraSectionCondition2="URL,^\\/feed\\/.*"
ExtraSectionFirstColumnTitle2="logiciel"
ExtraSectionFirstColumnValues2="UA,^([^\\/]*)"
ExtraSectionStatTypes2=PHBL
MaxNbOfExtra2=1000
MinHitExtra2=1

Cette fois-ci je ne liste pas l'URL mais le "User Agent" qui a fait la requête sur /feed/, ce qui me permet de lister les clients RSS utilisés. Enfin, je ne me contente pas seulement de lister les hits (H) et les pages (P), mais aussi la bande passante (B) et les dernières visites (L). On peut filtrer sur de nombreux critères, les voici :

URL
URLWITHQUERY
QUERY_STRING
REFERER
UA
HOSTINLOG
HOST
VHOST

La documentation d'Awstats possède une page consacrée aux Extra Sections dont je vous recommande la lecture. De même, un site nommé Internet Officer possède de nombreux exemples en rapport avec Google. Il est bien pratique, pour débuter avec les Extra Sections, de partir d'exemples fonctionnels proches (plus ou moins) du résultat qu'on souhaite obtenir. Enfin, le fichier de configuration d'Awstats reste en soi une excellente documentation grâce à la qualité des commentaires déjà présents.

Utilisation des plugins Awstats

2011-02-14T09:30:00+01:00

Nous avons vu dans un précédent billet comment mettre en oeuvre la génération de statistiques de visites avec Awstats. Nous allons maintenant enrichir et améliorer ces statistiques, avec dans un premier temps l'utilisation de plugins. Le prérequis pour ce billet est bien entendu d'avoir configuré Awstats et de posséder les modules Perl suivants : URI::Escape, Storable et Geo::IP.

Décoder correctement les phrases clés et les mots clés

Awstats permet de voir quels mots clés et quelles phrases clés ont été utilisés dans un moteur de recherche pour arriver sur votre site. Mais avec les jeux de caractères, Awstats peut avoir du mal à décoder les chaînes de caractères. Pour remédier à cela, il suffit d'activer le plugin decodeutfkeys dans notre fichier de configuration :

LoadPlugin="decodeutfkeys"

Accélération des recherches DNS

Dans notre configuration précédente, Awstats est paramétré pour faire une recherche DNS inverse des IP des visiteurs, ce qui peut prendre du temps. Il est donc possible de créer un fichier de cache pour accélérer ces recherches et éviter de faire 36 fois la même requête DNS. Pour cela, on active le plugin hashfiles :

LoadPlugin="hashfiles"

Géolocalisation des visiteurs

Il peut s'avérer très intéressant de savoir d'où viennent vos visiteurs selon le thème ou la langue du site : par exemple, un site rédigé en Français a dans le top 10 de ses visiteurs une adresse IP russe, une brésilienne et une chinoise (pays choisis au hasard). Si on regarde dans les logs, on se rend compte que 90% de leurs requêtes terminent en 404 ;) On va donc activer le plugin GeoIP :

LoadPlugin="geoip GEOIP_STANDARD /var/www/awstats/GeoIP.dat
LoadPlugin="geoip_city_maxmind GEOIP_STANDARD /var/www/awstats/GeoLiteCity.dat"

On remarque que dans le cas de GeoIP, il est nécessaire de disposer d'une base de données associant des plages d'adresses IP à un pays d'appartenance. Le fournisseur le plus connu pour ce type de bases de données est Maxmind, qui propose des solutions gratuites et payantes. Deux bases sont disponibles gratuitement, celle des pays et celle des villes. Ensuite, il reste à placer ces fichiers (décompressés) dans un répertoire accessible à Awstats; personnellement je le met au même endroit que les données de statistiques, donc /var/www/awstats ou /var/lib/awstats selon qu'on est sous NetBSD ou Linux. Les bases de données sont mises à jour chaque mois, pensez donc à régulièrement télécharger les nouvelles versions.

[Attention]{.underline} : ce type de traitement entraîne un ralentissement de la vitesse d'exécution d'Awstats, sur des gros sites cela peut très vite devenir gênant pour la carge CPU et mémoire de votre serveur.

Autres infos sur les IP des visiteurs

Plutôt que de copier-coller les IP de vos visiteurs dans un service de whois, il est possible d'utiliser le client whois d'Awstats via le plugin hostinfo :

LoadPlugin="hostinfo"

Au prochain épisode...

Nous avons maintenant quelques détails de plus sur nos visiteurs grâce aux plugins, il nous reste maintenant à mieux comprendre les visites via les directives "ExtraSection", qui fera l'objet d'un prochain billet... :)

Awstats

2011-01-31T09:30:00+01:00

Qu'est-ce qu'Awstats ? A quoi sert-il ?

Awstats est un outil web de statistiques pour un serveur web, FTP ou mail. Il permet donc de voir, pour un site internet par exemple, s'il y a beaucoup de visites, quelles sont les pages les plus visitées, quelle quantité de données est transférée, et "qui" vient le plus souvent visiter son site. Awstats est un logiciel libre, sous licence GNU GPL. Il peut être appelé dynamiquement, générer des pages HTML de statistiques, ou, grâce à des contributions externes de créer des fichiers PDF. Autre détail qui a son importance : Awstats se base sur les fichiers de log de votre serveur, il n'est donc pas à ma connaissance compatible avec les hébergements mutualisés.

De quoi ai-je besoin pour le faire fonctionner ?

Awstats a avant tout besoin de Perl ! Ensuite, selon votre besoin ou vos désirs, il faut que votre serveur web puisse exécuter des scripts CGI. Dans le cas d'Apache donc, pas besoin de mod_perl pour afficher vos statistiques Awstats, mais il faudra activer mod_cgi si vous souhaitez afficher dynamiquement les statistiques.

De plus, selon les fonctionnalités que vous souhaiterez activer, il est nécessaire d'avoir quelques modules Perl. Si vous souhaitez suivre ces billets, il peut être de bon ton d'installer les modules Perl suivants : URI::Escape, Storable, Geo::IP (et non Geo::IPfree) et Net::XWhois . Concernant NetBSD, j'ai installé les paquets suivants :

p5-Business-ISBN
p5-Business-ISBN
p5-Geo-IP
p5-MIME-Base64
p5-Net-XWhois
p5-Test-Simple
p5-URI

Installation

Awstats est généralement fourni dans les paquets de votre distribution Linux ou BSD favorite. Si ce n'est pas dans les dépôts officiels, il est fort probable que des dépôts alternatifs soient disponibles. Ainsi, pour RHEL et ses clones tels que CentOS, vous pouvez utiliser le dépôt EPEL. Si vous ne connaissez aucun dépôt ou que ceux-ci fournissent une version trop ancienne, vous pouvez utiliser l'archive disponible sur le site d'Awstats. Point non négligeable : comme il s'agit d'un programme Perl, nul besoin de le compiler, ce qui est fort appréciable !

Pour la suite : tous les exemples et codes proviennent d'une machine NetBSD 5, et Awstats est installé grâce au paquet disponible sur pkgsrc.

Première configuration

Nous avons donc installé Awstats. Avant de configurer Awstats

La configuration se situe dans /usr/pkg/etc/awstats/' et on y trouve déjà un fichier : awstats.model.conf''. Copions ce modèle et éditons-le :

root@vhost:/usr/pkg/etc/awstats# cp -p awstats.model.conf awstats.blog.anotherhomepage.org.conf
root@vhost:/usr/pkg/etc/awstats# vi awstats.blog.anotherhomepage.org.conf

Examinons maintenant la configuration, nous allons renseigner :

l'emplacement du fichier de logs
le nom (dns) du site web, ainsi que ses alias
renseigner les pages d'index
exclure Awstats des statistiques
exclure notre adresse IP des statistiques
et bien d'autres trucs encore !

Attention :

je n'affiche par la suite que les options que j'ai modifiées par rapport au modèle
ma configuration date un peu : mon fichier a été créé à l'époque d'Awstats 6.6, et de nouvelles options ont fait leur apparition

# Emplacement du fichier de log
LogFile="/var/log/httpd/blog-access.log"
# Nom DNS de notre site internet
SiteDomain="blog.anotherhomepage.org"
# Autres noms DNS possibles, ou adresse IP directement
HostAliases="localhost 127.0.0.1 www.blog.anotherhomepage.org 188.40.96.170"
# Faire une recherche inverse DNS sur les IP des visiteurs, cela permet d'avoir une meilleure visibilité en voyant
# les DNS inversedes FAI, mais attention : sur un gros site, cela peut énormément ralentir Awstats !
# Si vous avez un doute, mettez cette valeur à 0
DNSLookup=1
# Localisation des bases de données des statistiques, ici le chemin NetBSD !
# Sous GNU/Linux, le chemin est généralement /var/lib/awstats
DirData="/var/www/awstats"
# Localisation du GCI appelé par notre page de statistiques (awstats.pl)
DirCgi="/awstats"
# ...
DirIcons="/awstats/icon"
# Awstats peut proposer de mettre à jour en direct les statistiques via un bouton.
# C'est risqué, donc on désactive
EnableLockForUpdate=1
# Je préfère générer la page web en XHTML plutôt qu'en HTML
BuildReportFormat=xhtml
# C'est toujours bien les sauvegardes :)
KeepBackupOfHistoricFiles=1
# Page d'index par défaut
DefaultFile="index.html index.php"
# On peut s'exclure des visites : si on est en IP fixe, mieux vaut exclure son IP
# ainsi que celle du serveur et la boucle locale
SkipHosts="127.0.0.1 188.40.96.170"
# Ici j'exclue des statistiques le panneau d'admin de Dotclear, le répertoire des thèmes et quelques fichiers
# en rapport  avec un plugin
SkipFiles="REGEX[^\\/admin] REGEX[^\\/awstats] REGEX[^\\/themes] /?pf=partager2/img/delicious.png /?pf=partager2/img/digg.png /?pf=partager2/img/yahoomyweb.png /?pf=partager2/img/wikio.gif /?pf=partager2/img/sprite_partager2.png"
# Si vous avez des URL de type http://monsite.com/kikoo.php?variable=valeur
# vous pouvez différencier les requêtes selon ce que vaut "valeur"
# Mieux vaut faire de même pour votre referrer ;)
URLWithQuery=1
URLWithQueryWithoutFollowingParameters="PHPSESSID jsessionid"
URLReferrerWithQuery=1
# Je suis un peu parano sur les bord, je cherche à voir si des vers tentent d'accéder à mon site
LevelForWormsDetection=2
# Awstats affiche le top 10, sauf si on va dans le détail, où il affiche le top 1000 par défaut
# Moi j'en veux encore plus ! (mais la page est plus longue à charger)
MaxRowsInHTMLOutput=2000
# Je force la langue en Français, mais vous n'êtes pas obligé d'en faire autant
Lang="fr"
# J'affiche les stats sur les vilains vers qui polluent le Net
ShowWormsStats=HBL

Génération des statistiques de visites

Pour lancer la génération des statistiques, la commande est la suivante :

root@vhost:~# /usr/pkg/bin/perl /usr/pkg/awstats/bin/awstats.pl --config=blog.anotherhomepage.org --update

Affichage des statistiques de visites**Par défaut, la configuration suivante existe pour Apache :

root@vhost:~# cat /usr/pkg/etc/httpd/conf.d/awstats.conf
Alias /awstats/icon/ /usr/pkg/awstats/icon/
Alias /awstats/css/ /usr/pkg/awstats/css/
Alias /awstats/js/ /usr/pkg/awstats/js/

Alias /awstats/ /usr/pkg/awstats/cgi-bin/

<Location /awstats/>
        DirectoryIndex awstats.pl
        Options ExecCGI FollowSymLinks
        AddHandler cgi-script .pl
        AddHandler cgi-script .cgi
        order allow,deny
        allow from all
</Location>

Sous NetBSD, les fichiers .conf présents dans /usr/pkg/etc/httpd/conf.d/ sont automatiquement inclus dans votre configuration, ce qui ajoute un certain confort. A noter que de cette manière, vos statistiques sont accessibles au monde entier ! Vous pouvez utiliser un fichier htaccess ou les directives Allow avec votre IP si vous êtes en IP fixe pour restreindre l'accès aux statistiques.

Automatisation, multiplication et gestion de la rotation des logs

Tout ça c'est bien, mais une fois qu'on a 2-3 sites internet qui tournent, on ne va pas se connecter chaque jour sur notre serveur pour lancer une mise à jour par site. Il est possible de remédier à cela grâce à un utilitaire fourni avec Awstats : awstats_updateall.pl permet de mettre à jour tous les sites configurés en une seule commande ! En utilisation dans une crontab, tout est automatisé :) Exemple :

root@vhost:~# crontab -l | grep -i awstats
# Awstats :
10      0-23/4  *       *       *       /usr/pkg/bin/perl /usr/pkg/awstats/bin/awstats_updateall.pl now -awstatsprog=/usr/pkg/awstats/cgi-bin/awstats.pl -configdir=/usr/pkg/etc/awstats/ > /dev/null

Et voici nos statistiques mises à jour toutes les quatre heures, à la dixième minute (00h10, 4h10, 8h10...)

Si vous effectuez une rotation de vos logs avec logrotate, le plus intelligent est encore d'ajouter votre mise à jour de statistiques dans la configuration de logrotate, comme le détaille la FAQ d'Awstats.

Au prochain épisode...

Cette configuration basique et fonctionnelle permet d'avoir des statistiques intéressantes, mais nous pouvons aller plus loin, comme par exemple avec la géolocalisation d'adresses IP et l'utilisation d'autres plugins, et même aller jusqu'à créer nos propres filtres pour avoir des statistiques sur certaines parties du site par exemple.

Commentaires

Le 16/02/2011 11:49 par M@T D.

"Autre détail qui a son importance : Awstats se base sur les fichiers de log de votre serveur, il n'est donc pas à ma connaissance compatible avec les hébergements mutualisés" > Oui et non... Mutualisé au sens strict, avec un prestataire qui te fourni l'espace web (et donc pas d'accès sur admin sur la machine), je suis d'accord.

Mais si c'est un serveur que tu administres, rien ne t'empêche de splitter les fichiers de logs Apache (access et error) pour chaque VirtualHost, de créer plusieurs fichiers de conf awstat, et d'ordonnancer plusieurs tâches Cron pour obtenir des stats propres à chaque site.

;-)

Le 16/02/2011 19:48 par Nils

Je n'ai jamais vu de prestataire fournir un hébergement mutualisé où tu peux administrer ton serveur. En général quand tu as un accès administrateur à l'OS, tu es sois sur du VPS (Virtual Private Server), soit sur du RPS (Real Private Server, qui a juste de l'espace disque sur un SAN), soit un véritable serveur dédié. Et pour moi il s'agit d'une question de bon sens de séparer l'access_log de l'error_log et bien entendu d'avoir un couple de log par virtual host.

Pourquoi ordonnancer plusieurs tâches cron quand on a awstats_updateall.pl comme je l'ai indiqué ?

Le 22/02/2011 13:50 par M@T D.

Si je te dis que je considère que je fais de l'hébergement mutualisé chez moi... Tu comprends mieux mon point de vu ? Au sens, strict du terme, je suis tout à fait d'accord avec toi ;-)

Sinon, j'avais pas vu la partie sur awstats_updateall.pl... Effectivement, très pratique.

Recherche colorée dans les logs avec perl

2010-02-13T12:35:00+01:00

Voici un petit one-liner assez sympathique, dont on m'avait parlé dans la semaine et sur lequel je suis tombé par hasard en cherchant autre chose. Le principe est d'afficher dans une autre couleur un texte donné dans une recherche, comme par exemple une erreur précise dans un fichier de logs. Sur une machine j'ai des problèmes avec cron, je l'utilise donc de la manière suivante :

root@lolcathost:~# tail -f /var/log/syslog | perl -pe 's/cron/\\e[1;31m$&\\e[0m/ig'

On remarque une différence avec le lien indiqué plus haut, j'ai mis "/ig" à la fin au lieu de "/g". Pourquoi? J'avais besoin de faire la recherche sans tenir compte de la casse, et j'ai trouvé l'option suite à une rapide recherche. Je devrais vraiment me mettre à perl, ça me semble vraiment efficace et pratique :-)

Pour ceux qui pensent que j'ai fait une faute de frappe dans la recopie du prompt, je leur recommande d'aller voir ici.

Commentaires

Le 25/04/2010 10:46 par karles

Plus simple encore "grep --color" met en couleur la chaine recherché. Pour toute la ligne le one-liner en perl reste le plus efficace.

Karles