Another Home Page Blog

Antisèches Cisco, réseau et autres

Nils — Thu, 20 Dec 2012 09:30:00 +0100

Session de surf en mode "veille technologique" (sauf que je suis en congés), en passant par l'excellent Planet CentOS, je suis tombé sur un post de blog menant à des posters antisèches pour différents domaines ! C'est super intéressant, on y trouve plein de configurations Cisco pour les protocoles de routage connus, les VPN IPsec, voire même des configurations Wi-Fi ! D'autres posters permettent de vite retrouver les bases, comme la notation CIDR IPv4, les filtres pour Wireshark ou quelques syntaxes wiki bien utilisées.

Pour couronner le tour, le site propose non seulement le téléchargement de ces antisèches au format PDF, mais aussi l'impression et l'envoi d'une de ces antisèches, au format poster bien entendu !

Si vous êtes intéressés, le site en question est Packet Life, et l'antisèche disponible en poster imprimé est celle-ci.

Nombre d'occurrences dans un fichier - remix

Nils — Mon, 01 Oct 2012 13:37:00 +0200

Je détaillais dans un billet écrit il y a déjà un sacré bout de temps comment obtenir une sorte de top 10 des adresses IP effectuant le plus de requêtes dans un fichier de log Apache. J'ai décidé de revenir dessus, et de faire quelques déclinaisons de ce one-liner selon les recherches. Attention si vous voulez copier-coller ces exemples, ils ont été réalisés sous NetBSD, et la commande sort n'a pas les mêmes options. Grosso modo pour le moment, j'ai vu que là où on écrit sort -g sous GNU/Linux, il faut écrire sort -n sous NetBSD. J'ai aussi décidé de me limiter à un top 5 dans l'affichage, afin d'éviter un billet trop long.

Revenons donc d'abord sur le one-liner de base, les IP qui font le plus de requêtes, avec à gauche, l'adresse IP, et à droite le nombre de hits :

root@dev:/var/log/httpd# awk '{frequencies[$1]++;} END {for (field in frequencies) printf "%s\t%d\n" , field , frequencies[field];}' < ./access.log | sort -nr -k 2,2 | head -5
81.X.Y.Z    6414
208.F.B.I 1578
178.K.G.B  1301
67.D.S.T  1179
77.C.I.A     1157

Ensuite, effectuons pareil mais sur les URLs visitées, toujours avec le nombre de hits à droite :

root@dev:/var/log/httpd# awk '{frequencies[$7]++;} END {for (field in frequencies) printf "%s\t%d\n" , field , frequencies[field];}' < ./access.log | sort -nr -k 2,2 | head -5
/post/2008/05/17/installation-de-phpmyadmin-sur-CentOS-5        7787
/post/2008/05/24/Installation-de-mod_gnutls-sur-CentOS-5        4010
/post/2008/06/20/Utilisateurs-virtuels-sous-CentOS-5-avec-base-de-donnees-MySQL 1910
/post/2007/11/28/Installation-et-configuration-dun-serveur-dedie-OpenArena-071  1284
/post/2009/11/09/Utilisation-transparente-d-une-passerelle-SSH  1266

Comme il ne s'agit que de modifier le numéro du champ, on peut aussi voir les codes de retour HTTP les plus obtenus :

root@dev:/var/log/httpd# awk '{frequencies[$9]++;} END {for (field in frequencies) printf "%s\t%d\n" , field , frequencies[field];}' < ./access.log | sort -nr -k 2,2 | head -5
200     57019
304     6156
404     1797
500     114
403     20

On peut ensuite aller chercher avec grep les pages causant des erreurs 500 ou 404.

Toujours avec la même facilité (un simple numéro de champ à modifier), on peut afficher les referers qui amènent le plus de hits :

root@dev:/var/log/httpd# awk '{frequencies[$11]++;} END {for (field in frequencies) printf "%s\t%d\n" , field , frequencies[field];}' < ./access.log | sort -nr -k 2,2 | head -5
"-"     44306
"http://blog.anotherhomepage.org/post/2008/05/17/installation-de-phpmyadmin-sur-CentOS-5"       3443
"http://blog.anotherhomepage.org/post/2008/06/20/Utilisateurs-virtuels-sous-CentOS-5-avec-base-de-donnees-MySQL"        686
"http://blog.anotherhomepage.org/post/2009/11/09/Utilisation-transparente-d-une-passerelle-SSH" 552
"http://www.google.fr/search?q=phpmyadmin+centos&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:fr:official&client=firefox-a"   401

On remarque que beaucoup n'ont pas de referer, mais il est probable que ce soient des hits sur le flux RSS. On remarque aussi que j'ai beaucoup de referers de mon propre site, il me suffit de les filtrer si je ne veux pas les afficher. Afin de rendre le traitement plus rapide, je décide de mettre la commande grep en premier dans mon traitement :

root@dev:/var/log/httpd# grep -v "blog.anotherhomepage.org" access.log | awk '{frequencies[$11]++;} END {for (field in frequencies) printf "%s\t%d\n" , field , frequencies[field];}' | sort -nr -k 2,2 | head -5
"-"     44306
"http://www.google.fr/search?q=phpmyadmin+centos&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:fr:official&client=firefox-a"   401
"http://www.google.fr/search?q=centos+phpmyadmin&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:fr:official&client=firefox-a"   166
"http://forum.hardware.fr/hfr/OSAlternatifs/Installation/resolu-centos-phpmyadmin-sujet_70143_1.htm"    121
"http://www.google.fr/" 77

Reprenons notre affichage des URLs les plus visitées, mais cette fois prenons en compte les méthodes (GET, HEAD, POST) et la version du protocole HTTP :

root@dev:/var/log/httpd# awk -F "\"" '{frequencies[$2]++;} END {for (field in frequencies) printf "%s\t%d\n" , field , frequencies[field];}' < ./access.log | sort -nr -k 4| head -5
GET /post/2008/05/17/installation-de-phpmyadmin-sur-CentOS-5 HTTP/1.1   4266
GET /post/2008/05/17/installation-de-phpmyadmin-sur-CentOS-5 HTTP/1.0   3521
GET /post/2008/05/24/Installation-de-mod_gnutls-sur-CentOS-5 HTTP/1.1   2181
GET /post/2008/05/24/Installation-de-mod_gnutls-sur-CentOS-5 HTTP/1.0   1829
GET /post/2008/06/20/Utilisateurs-virtuels-sous-CentOS-5-avec-base-de-donnees-MySQL HTTP/1.0    1193

On note ici l'utilisation de l'option "-F" de awk pour changer le motif du séparateur de champ, ce qui me permet d'avoir des champs avec espace.

Enfin, dernier exemple, trions maintenant les User-Agents :

root@dev:/var/log/httpd# awk -F "\"" '{frequencies[$6]++;} END {for (field in frequencies) printf "%d\t%s\n" , frequencies[field], field;}' < ./access.log | sort -nr | head -5
10539   Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1) VoilaBot BETA 1.2 (support.voilabot@orange-ftgroup.com)
6493    Mozilla/4.0 (compatible; MSIE 4.01; Windows CE; PPC; 240x320; SPV M700; OpVer 19.123.2.733) OrangeBot-Mobile 2008.0 (mobilesearch.support@orange-ftgroup.com)
4188    Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp)
3269    msnbot/2.0b (+http://search.msn.com/msnbot.htm)
3017    Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)

J'ai décidé cette fois-ci d'afficher le nombre d'occurrences à gauche, car le nombre de champs (séparés par un espace) n'est plus fixe dans le cas des User-Agents. Mais au moment d'écrire cette phrase, j'ai de nouveau parcouru la page de manuel de sort et j'ai pu voir qu'il est possible de spécifier le séparateur de champ (option -t). J'ai utilisé le caractère $ pour séparer le nombre d'occurrences du libellé du User-Agent, suivi de 'tr' pour le remplacer par une tabulation :

awk -F "\"" '{frequencies[$6]++;} END {for (field in frequencies) printf "%s$%d\n" , field , frequencies[field];}' < ./access.log | sort -nr -t$ -k 2,2| tr $ "\t" | head -5
Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1) VoilaBot BETA 1.2 (support.voilabot@orange-ftgroup.com)  10539
Mozilla/4.0 (compatible; MSIE 4.01; Windows CE; PPC; 240x320; SPV M700; OpVer 19.123.2.733) OrangeBot-Mobile 2008.0 (mobilesearch.support@orange-ftgroup.com)        6493
Mozilla/5.0 (compatible; Yahoo! Slurp/3.0; http://help.yahoo.com/help/us/ysearch/slurp) 4188
msnbot/2.0b (+http://search.msn.com/msnbot.htm) 3269
Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)        3017

Le choix du caractère de séparateur de champ est discutable, mais il ne change pas qu'après réflexion, l'affichage de la commande précédente me semble plus lisible. Et je pense qu'afficher le nombre d'occurences en permier sera plus lisible dans d'autres cas, comme le referer ou l'URL.

Couleurs dans le terminal

Nils — Mon, 05 Dec 2011 08:40:00 +0100

Pour beaucoup de gens, la vue d'un terminal, en général en texte blanc sur fond noir (mais aussi en noir sur fond blanc ou beige sur certaines distributions), peut s'avérer très peu attrayante. En ce qui me concerne je me suis accommodé et j'ai fini par apprécier le terminal, grâce à quelques modifications cosmétiques apportant de la couleur. Je trouve ainsi mon environnement beaucoup plus lisible.

Le prompt

Dans bash (et probablement dans d'autres shells), il est possible de modifier l'apparence du prompt via la variable d'environnement PS1. Regardons quelle est la valeur de PS1 sur un système CentOS (les simples quotes visent à montrer qu'il y a un espace à la fin) :

[root@orgrimmar ~]# echo "PS1 vaut: '$PS1'"
PS1 vaut: '[\u@\h \W]\$ '

Il est possible d'en modifier l'apparence avec de nombreux paramètres, tels que la couleur, certaines informations. Par exemple, j'ai choisi d'appliquer la personnalisation suivante sur tous mes environnements bash :

nils@arreat:~$ echo "PS1 vaut: '$PS1'"
PS1 vaut: '\[\]\u\[\]@\[\]\h\[\]:\w\[\]\$\[\] '

Ce qui est gênant, c'est que si ma variable d'environnement possède des couleurs, leurs codes ne sont pas affichés mais directement interprétés. En réalité, ma variable PS1 vaut :

# récupartion depuis mon bashrc :
PS1=$'\[\E[01;32m\]\u\[\E[0m\]@\[\E[01;36m\]\h\[\E[0m\]:\w\[\E[01;32m\]\$\[\E[0m\] '

Le nom d'utilisateur et le signe "$" sont verts, tandis que le nom d'hôte est bleu. J'ai réalisé une variante pour l'utilisateur root où le vert est remplacé par du rouge.

Pour essayer, rien de plus simple : il suffit d'exporter la variable d'environnement PS1 avec une nouvelle valeur :

[root@orgrimmar ~]# echo "PS1 vaut: '$PS1'"
PS1 vaut: '[\u@\h \W]\$ '
[root@orgrimmar ~]# PS1=$'\[\E[01;32m\]\u\[\E[0m\]@\[\E[01;36m\]\h\[\E[0m\]:\w\[\E[01;32m\]\$\[\E[0m\] '
root@orgrimmar:~# echo "PS1 vaut: '$PS1'"
PS1 vaut: '\[\]\u\[\]@\[\]\h\[\]:\w\[\]\$\[\] '

Il est possible d'aller plus loin, comme de remplacer \h par \H pour obtenir le nom complet de la machine, d'insérer la date, d'afficher le prompt en gras... Vous trouverez chez Nixcraft les différents codes pour démarrer et stopper une couleur, ainsi que pour la mise en gras.

Si vos expérimentations amènent un résultat peu plaisant, deux possibilités : la première consiste à appliquer de nouveau l'ancienne valeur PS1, si vous avez copié son contenu ailleurs, ou d'aller le chercher par exemple dans /etc/bashrc ; la deuxième consiste tout simplement à fermer puis relancer votre terminal.

Une fois que votre nouveau prompt vous plaît, vous voulez rendre le changement définitif. Il est possible d'éditer son fichier .bashrc, .bash_profile ou .profile pour cela. Si vous souhaitez que ce changement soit effectif pour tous les utilisateurs, il est possible de modifier directement /etc/profile ou /etc/bashrc, mais je ne vous le recommande pas : il est possible de mal éditer le fichier et de supprimer accidentellement des commandes utiles, et donc de mettre en vrac son système.

Pour CentOS/RHEL/Fedora, j'ai pris l'habitude de créer un fichier nommé /etc/profile.d/prompt.sh : en effet, le fichier /etc/profile de ces distributions charge tous les .sh situés dans /etc/profile.d. Il devient donc aisé d'ajouter ou de retirer des personnalisations shell comme des alias, le prompt, et d'autres variables d'environnement qui affecteront tous les utilisateurs.

Pour NetBSD, j'ai choisi de créer un fichier /usr/pkg/etc/bashrc contenant ces personnalisations, et d'ajouter le contenu suivant dans /etc/profile (qui, par défaut, ne contient que des commentaires) :

if [ "${BASH_no}" != "no" ]; then
                 [ -r /usr/pkg/etc/bashrc ] && . /usr/pkg/etc/bashrc
fi

De la couleur dans ls

Selon votre système, cette option peut ne pas être disponible : cela fonctionne avec CentOS 4 et 5, mais pas avec NetBSD. Il s'agit tout simplement d'utiliser l'option --color, qui peut être complétée, par exemple --color=auto ou --color=tty. D'où viennent ces couleurs ? De la variable d'environnement LS_COLORS. On peut donc modifier cette variable pour afficher les couleurs différemment, et consulter la page de manuel de dircolors pour plus de détails.

Grep

La commande grep possède une option --color, parfois activée par défaut dans un alias sur certaines distributions. Elle colore en rouge la chaîne de caractères recherchée, que ce soit sous CentOS ou NetBSD.

Pages de manuel en couleur

most permet de visualiser un texte, comme more ou less. A la différence de ces deux derniers, most affiche les pages de manuel en couleur. Pour cela, vous pouvez utiliser la commande suivante :

PAGER=most man <votrecommande>

Pour que ce soit définitif, exportez la variable d'environnement PAGER=most. Attention toutefois, vérifiez que vous n'avez pas un PAGER=more qui traîne quelque part. Concernant la disponibilité du package, on peut le trouver dans pkgsrc ainsi que dans RPMForge.

Colorer ses fichiers de log

Un outil très pratique pour avoir des fichiers de log en couleurs est ccze. Il m'arrive de l'utiliser de la manière suivante :

tail -f /chemin/vers/mon/log/apache | ccze

Je peux aussi m'en servir sur un fichier qui n'est pas mis à jour en direct, en duo avec less :

ccze -A < monfichierdelog | less -R

Ce petit bijou connaît de nombreux formats de fichiers de log, et les rend du coup plus agréables à lire. C'est disponible dans pkgsrc et dans EPEL

Un top en couleur ?

Htop est une version améliorée de top qui, en plus d'afficher la couleur, affiche les taux d'occupation processeur et mémoire d'une manière un peu graphique. A noter cependant que cet outil est d'abord développé pour Linux, et qu'il faut, sous NetBSD, monter /proc avec l'option linux (celle-ci est cependant différente de la couche de compatibilité binaire linux). Htop est disponible dans pkgsrc et dans EPEL

Coloration syntaxique avec VIm

Vous trouvez vi trop morne et déprimant ? Installez VIm et activez la coloration syntaxique ! Souvent, seul vi est installé. Côté pkgsrc, le package se nomme vim et a pour dépendance vim-share. Côté Red Hat, on installera vim-enhanced (dispo dans les dépôts de base). Une fois ceci fait, ajoutez dans votre répertoire home un fichier .vimrc contenant au moins :

syn on
set nu

Ensuite, éditez un script shell, par exemple. Vous verrez la couleur et les numéros de ligne. Pour ceux qui comme moi on un fond noir ou sombre, on ajoutera la directive suivante à son .vimrc :

set bg=dark

La coloration syntaxique s'adaptera ainsi au fond de votre terminal.

Et voilà ! C'est Noël sur votre shell :-)

Lancement de GNU Screen en arrière-plan

Nils — Mon, 28 Nov 2011 09:30:00 +0100

Les entrailles de GNU Screen (que j'abrègerai en screen par la suite) sont parfois difficiles à comprendre. L'histoire commence ainsi : je possède une machine NetBSD, un peu bruyante, que j'allume le matin au lever et que j'éteins le soir au coucher. J'utilise screen sur cette machine, et j'aimerais, par grosse fénéantise, que ce dernier se lance au démarrage de ma machine, en mode détaché. De la sorte, il ne me reste qu'à lancer un bon vieux screen -r lorsque que je m'y connecte et mon comportement ne change pas d'autres machines allumées 24h/24 : je me connecte, je screen -r et je suis prêt.

Jusque-là rien de bien particulier : un petit tour dans la page de manuel m'apprend que cela est déjà possible :

screen -d -m

Cette commande permet de faire en sorte qu'il démarre en mode détaché, et que c'est justement fait pour un éventuel script de démarrage. En bref, la paix dans le monde, mes amis :-)

Je me précipite donc sur ${EDITOR} et entame l'écriture épique d'un script shell qui va lancer screen en mode détaché sous l'identité de l'utilisateur que je suis, avec le fichier .screenrc qui convient. Le script fonctionne, le script fonctionne au démarrage de la machine (c'est mieux, hein ?), toujours la paix dans le monde, avec les oiseaux qui chantent, nous sommes dans un rêve :-)

Donc, plein d'illusions, je lance la commande screen -r . Et là, c'est le drame : le prompt de mon shell (bash) n'est pas coloré, et n'affiche pas le répertoire courant. Après avoir demandé conseil à mon moteur de recherche favori, je me rend compte que dans ce cas, screen a eu la bonne idée de remplacer la variable d'environnement PS1 (qui définit le prompt) par une valeur autre. D'où vient-elle ? Je ne le savais pas encore. J'ai essayé de redéfinir cette variable dans mon fichier de configuration .screenrc, sans succès. En désespoir de cause, je tente un unset PS1. Victoire ! J'ai mon prompt personnalisé ! je suis joie, bonheur, les oiseaux chantent, la paix dans le monde, tout ça tout ça...

Jusqu'à ce que j'édite un fichier texte. Et là, c'est le drame (à nouveau) : mon éditeur de texte, VIm, dispose d'une fonction de coloration syntaxique que j'active par défaut. C'est trèèèès pratique. J'active aussi la numérotation des lignes. Mais là, pas de couleur. Il s'agit pourtant d'un type de fichier connu. Je tente ma chance avec d'autres programmes disposant d'un affichage coloré, sans succès non plus. Après quelques bidouillages, je me rend compte qu'en changeant la variable d'environnement TERM de screen à xterm-color, j'obtiens à nouveau la couleur. En désespoir de cause j'ajoute export TERM=xterm-color au fichier /usr/pkg/etc/bashrc (ce qui m'évite de copier-coller un .bashrc dans le $HOME de mon utilisateur et de root), je relance le script et là : couleur :-)

Avec le recul de l'écriture de ce billet, je me suis rendu compte que lorsque j'utilise screen -d -m, ce dernier charge mon fichier .profile (qui charge .shrc). Ces deux fichiers m'ont posé problème dans le passé : par exemple .profile contient deux exports qui entrent conflit avec mon bashrc, export EDITOR=vi et export PAGER=more (j'utilise vim et most à la place). J'ai aussi remarqué la ligne suivante dans le fichier .shrc :

export PS1="$(whoami)@$(hostname -s)$ "

Tiens, c'est marrant, c'est exactement le prompt que j'avais lors de mon premier problème... ;-)

Bref, ma solution n'est peut-être pas la plus élégante, mais au moins ça fonctionne. Mais comme on me l'a fait remarquer il y a presque deux mois, sur les systèmes Unix : There Is More Than One Way To Do It (Il y a plus d'une façon de le faire).

Ajouter des robots dans Awstats

Nils — Mon, 21 Nov 2011 09:30:00 +0100

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

Installation de phpMyAdmin sur CentOS 6 - suite

Nils — Mon, 17 Oct 2011 09:30:00 +0200

Résumé de l'épisode précédent

Lors de mon précédent billet sur l'installation et la configuration de phpMyAdmin sur CentOS 6, nous avions obtenu une installation fonctionnelle, mais perfectible. Nous allons voir ensemble comment rendre l'installation plus confortable et tenter de la sécuriser un peu.

Authentification par cookie

Lors de la connexion à phpMyAdmin, c'est une authentification de type HTTP qui est envoyée. Sachant que nous n'avons pas encore activé HTTPS, les identifiants circulent en clair sur le réseau. De plus, à chaque fois qu'on ferme la fenêtre ou l'onglet du navigateur, il faut s'authentifier à nouveau. Le cookie devrait donc aider. Pour activer ce mécanisme, éditons le fichier de configuration de phpMyAdmin :

[root@crashtest ~]# vi /etc/phpMyAdmin/config.inc.php

A la ligne 41, on trouvera l'expression suivante :

$cfg['Servers'][$i]['auth_type']     = 'http';      // Authentication method (config, http or cookie based)?

Il suffit donc de remplacer 'http' par 'cookie' puis d'enregistrer le fichier. Le paramètre 'config' est à manipuler avec la plus grande précaution, et nécessite de renseigner les identifiants dans les champs suivants, ce qui n'est pas du tout sécurisé à mon sens. Une fois la modification effectuée, une (jolie ?) page d'identification devrait apparaître en lieu et place de l'horrible notification du navigateur demandant le login et le mot de passe. En prime, il est possible de choisir la langue :-)

Maintenant, un message assez étrange risque d'apparaître lors de vos prochaines connexions, en bas de l'interface de phpMyAdmin : Vous devez ajouter dans le fichier de configuration une phrase de passe secrète (blowfish_secret). Allons donc éditer de nouveau le fichier de configuration, à la ligne 14 :

$cfg['blowfish_secret'] = ''; /* YOU MUST FILL IN THIS FOR COOKIE AUTH! */

Et entre les guillemets simple, on insère une phrase de passe. Quelques exemples :

je vois un gnou faire de la bicyclette
je ne sais pas programmer en python (ou perl, java, c, ruby, ce que vous voulez)
aieruhgpauOUGYVaerhg 07856qorieghg (oui, l'aléatoire fonctionne aussi)

Le but n'est pas de fournir une phrase intelligible ou facilement mémorisable, mais une suite de caractère assez longue pour chiffrer le mot de passe dans le cookie. Il ne sera pas nécessaire de réutiliser cette phrase de passe.

HTTPS

L'authentification par cookie apporte un mieux, mais celui-ci peut toujours être intercepté et rejoué par quelqu'un de malintentionné. De plus l'intercepteur pourra examiner le traffic et en retirer les commandes jouées, ou pourquoi pas le contenu des base de données. L'un des moyens d'empêcher cette interception est de chiffrer le trafic entre la machine cliente et le serveur hébergeant phpMyAdmin et MySQL. Pour cela nous allons activer mod_ssl dans Apache afin de naviguer en HTTPS dans phpMyAdmin.

Installons donc mod_ssl :

[root@crashtest ~]# yum install mod_ssl
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * epel: mirrors.ircam.fr
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package mod_ssl.x86_64 1:2.2.15-5.el6.centos set to be updated
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package        Arch          Version                         Repository   Size
================================================================================
Installing:
 mod_ssl        x86_64        1:2.2.15-5.el6.centos           base         85 k

Transaction Summary
================================================================================
Install       1 Package(s)
Upgrade       0 Package(s)

Total download size: 85 k
Installed size: 183 k
Is this ok [y/N]: y
Downloading Packages:

mod_ssl-2.2.15-5.el6.centos.x86_64.rpm                   |  85 kB     00:00

Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction

Installing     : 1:mod_ssl-2.2.15-5.el6.centos.x86_64                     1/1

Installed:
  mod_ssl.x86_64 1:2.2.15-5.el6.centos

Complete!

Relançons Apache :

[root@crashtest ~]# service httpd restart
Arrêt de httpd :                                           [  OK  ]
Démarrage de httpd :                                       [  OK  ]

Et rendons-nous sur phpMyAdmin, en HTTPS. Dans mon cas l'url est https://crashtest/phpmyadmin/ . Un message du navigateur signale alors que le certificat utilisé pour se connecter est auto-signé.

Il est courant d'accepter le certificat et de le mémoriser : à plus forte raison s'il s'agit d'une machine de tests ou de développement, il suffit de s'assurer que le certificat ne changera pas en le mémorisant dans le navigateur; si jamais ce message devait à nouveau s'afficher, soit vous avez réinstallé le serveur ou changé les certificats, soit un petit malin tente une attaque de type "homme du milieu" (man in the middle en anglais).

Il est aussi possible d'accepter le certificat sans pour autant le mémoriser, et (faire) créer les certificats adéquats, selon votre type d'organisation ; les grosses entreprises possèdent leur propre autorité de certification et la déploient sur leurs postes de travail. Si votre serveur est directement accessible depuis Internet, de nombreux prestataires proposent, gratuitement ou non, de générer un certificat qu'il vous faudra ensuite installer en lieu et place de ceux par défaut. Cela peut vous éviter de vérifier manuellement sur chaque nouvelle machine cliente qu'il s'agit du bon certificat.

La mise en œuvre détaillée d'un serveur HTTPS et d'une infrastructure de gestion de certificats SSL d'entreprise (appelée aussi PKI de l'anglais Public Key Infrastructure) ne fait pas partie des objectifs de ce billet, par conséquent elle est laissée en exercice au lecteur.

Notre serveur accepte donc les connexions HTTP en clair et les connexions HTTPS chiffrées.

Pare-feu

En plus de chiffrer des connexions, il est possible de les filtrer. Dans le précédent billet, nous avons vu qu'Apache peut interdire ou accepter certains clients suivant leur adresse IP. Il est possible, avec un pare-feu (firewall en anglais), de filtrer les connexions Apache comme MySQL ou SSH et d'effectuer un contrôle plus fin sur les connexions.

Sur un système GNU/Linux, en particulier CentOS, le pare-feu de référence est Netfilter (qui fournit entre autres la commande iptables). La plupart des autres projets de pare-feu pour GNU/Linux sont généralement des surcouches à Netfilter.

Attention ! il est très facile, lorsqu'on manipule des règles de filtrage de connexions réseau, de scier la branche sur laquelle on est assis. Si bloquer accidentellement les connexions réseau lorsqu'on est devant la machine n'est pas bien grave, couper la connexion SSH qu'on utilise oblige à se déplacer, couper le pare-feu une fois devant la machine, puis repartir à son poste et se reconnecter.

Pour éviter ce genre de désagrément, il est possible de planifier une tâche qui coupe le firewall, par exemple toutes les 10 minutes. Ainsi, dès qu'on se rend compte que la machine ne répond plus à rien sur le réseau, il ne reste qu'à attendre 10 minutes tout au plus pour que la machine soit à nouveau accessible. L'inconvénient est qu'il faut réussir à faire ses modifications en moins de 10 minutes ! Nous allons donc éditer la crontab :

[root@crashtest ~]# crontab -e

Il est fort probable qu'elle soit vide, puisqu'il s'agit de la crontab de root et que la machine est fraîchement installée. Ajoutons la ligne suivante :

*/10    *       *       *       *       /etc/init.d/iptables stop > /dev/null 2>&1

Et voilà ! Toutes les 10 minutes, le pare-feu sera désactivé. Le temps d'effectuer une modification, et de la valider. Attention cependant, une fois que les changements seront validés, penser à effacer cette ligne, ou à la commenter. Pour plus d'information : la page de manuel. Une fois le garde-fou mis en place, passons aux choses sérieuses : définir les règles de filtrage à mettre en place, puis les mettre en place.

Afin de rester dans les clous de la distribution, nous n'allons pas créer un script de pare-feu personnalisé, mais utiliser le fichier déjà en place pour sauvegarder les règles. Ce fichier est /etc/sysconfig/iptables, mais comme indiqué en anglais en tête de ce fichier, il n'est pas recommandé de l'éditer manuellement. Nous allons donc lancer le pare-feu, ajouter des règles avec la commande iptables, vérifier leur bon fonctionnement, les sauvegarder, et vérifier la sauvegarde.

Lancement du pare-feu :

[root@crashtest ~]# service iptables start
iptables : Application des règles du pare-feu :            [  OK  ]

Vérification des règles actuellement activées :

[root@crashtest ~]# service iptables status
Table : filter
Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination
1    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
2    ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0
3    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
4    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:22
5    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:25
6    REJECT     all  --  0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT)
num  target     prot opt source               destination
1    REJECT     all  --  0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination

Et si on tente de se connecter à phpMyAdmin, cela ne fonctionne plus. Il faut donc accepter les connexions vers le port 80 (HTTP) et 443 (HTTPS). Nous allons insérer dans la chaine INPUT avant la règle numéro 5 (celle qui accepte le port 25 tcp) une règle acceptant le port 80 :

[root@crashtest ~]# iptables -I INPUT 5 -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT

Si on se connecte à phpMyAdmin, cela fonctionne en HTTP, mais pas en HTTPS. Continuons, cette fois insérons notre règle avant la numéro 6 (décalage oblige du fait de notre insertion précédente) :

[root@crashtest ~]# iptables -I INPUT 6 -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT

Voilà, maintenant nous accédons à phpMyAdmin en HTTPS. Vérifions les règles en mémoire pour comparaison avec la situation précédente :

[root@crashtest ~]# service iptables status
Table : filter
Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination
1    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
2    ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0
3    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
4    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:22
5    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:80
6    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:443
7    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:25
8    REJECT     all  --  0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT)
num  target     prot opt source               destination
1    REJECT     all  --  0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination

A noter que la commande iptables -L -n donne le même résultat, et pourrait servir sur d'autres distributions Linux. A présent, sauvegardons notre configuration :

[root@crashtest ~]# service iptables save
iptables : Sauvegarde des règles du pare-feu dans /etc/sysconfig/iptables : [  OK  ]

Vérifions la sauvegarde :

[root@crashtest ~]# cat /etc/sysconfig/iptables
# Generated by iptables-save v1.4.7 on Thu Sep 22 20:34:19 2011
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1118:858094]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 25 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT
# Completed on Thu Sep 22 20:34:19 2011

On peut donc voir que les règles acceptant les ports 80 sont bien sauvegardées. La règle autorisant le port 25 n'est pas utile, elle fut ajoutée en exemple lors du billet sur une installation minimaliste de CentOS 6. Le retrait de cette règle est laissé en exercice au lecteur ;-)

Une fois les règles en place donnant satisfaction, il faut penser à retirer le garde-fou en éditant la crontab : on peut alors supprimer la ligne désactivant iptables, ou la mettre en commentaire en place le caractère "#" devant. Après le retrait du garde-fou, on peut activer le pare-feu au démarrage :

[root@crashtest ~]# chkconfig --list iptables
iptables        0:arrêt 1:arrêt 2:arrêt 3:arrêt 4:arrêt 5:arrêt 6:arrêt
[root@crashtest ~]# chkconfig iptables on
[root@crashtest ~]# chkconfig --list iptables
iptables        0:arrêt 1:arrêt 2:marche        3:marche        4:marche        5:marche        6:arrêt

Base de données phpMyAdmin

phpMyAdmin est maintenant un outil complet avec de nombreux paramètres. Certains peuvent être utilisés via le fichier de configuration, mais pour d'autres, une base de données est nécessaire. D'ailleurs, selon le paquet phpMyAdmin installé (une version à jour est arrivée pendant l'écriture des deux billets), vous pouvez avoir le message suivant en bas de l'interface : Le stockage de configurations phpMyAdmin n'est pas complètement configuré, certaines fonctionnalités ont été désactivée. Pour en connaître la raison, cliquez ici. Dans la version plus récente, cet avertissement a été retiré.

Utilisons phpMyAdmin pour créer un nouvel utilisateur dit de contrôle (via l'onglet Privilèges), et appelons-le tout simplement phpmyadmin. Le paramètre client est Local, et on génèrera le mot de passe aléatoirement. Pensez à copier ce mot de passe ailleurs, on va en avoir besoin un peu plus tard. Toujours dans l'interface de création de l'utilisateur, cochons l'option Créer une base portant son nom et donner à cet utilisateur tous les privilèges sur cette base. Enfin, cliquons sur le bouton du bas : Créer un compte d'utilisateur. Une autre manipulation est nécessaire car l'utilisateur de contrôle a besoin d'un peu plus de droits. Pour aller plus vite, rechargeons les privilèges puis cliquons sur l'onglet SQL et entrons le texte suivant dans le champ (j'espère que vous avez bien copié le mot de passe généré de tout à l'heure ;-)):

GRANT USAGE ON mysql.* TO 'phpmyadmin'@'localhost' IDENTIFIED BY 'motdepassealeatoire';
GRANT SELECT (
    Host, User, Select_priv, Insert_priv, Update_priv, Delete_priv,
    Create_priv, Drop_priv, Reload_priv, Shutdown_priv, Process_priv,
    File_priv, Grant_priv, References_priv, Index_priv, Alter_priv,
    Show_db_priv, Super_priv, Create_tmp_table_priv, Lock_tables_priv,
    Execute_priv, Repl_slave_priv, Repl_client_priv
    ) ON mysql.user TO 'phpmyadmin'@'localhost';
GRANT SELECT ON mysql.db TO 'phpmyadmin'@'localhost';
GRANT SELECT ON mysql.host TO 'phpmyadmin'@'localhost';
GRANT SELECT (Host, Db, User, Table_name, Table_priv, Column_priv)
    ON mysql.tables_priv TO 'phpmyadmin'@'localhost';

Cliquons sur Exécuter et on nous signale que MySQL a retourné des résultat vides. Pensons à recharger les privilèges (dans l'onglet Privilèges Encore une chose. Il nous faut peupler la base de données créée pour phpMyAdmin. Pour cela, revenons dans le shell de notre serveur et utilisons le fichier SQL fourni par phpMyAdmin :

[root@crashtest ~]# mysql -u root -p < /usr/share/phpMyAdmin/scripts/create_tables.sql

Maintenant éditons à nouveau le fichier de configuration de phpMyAdmin :

[root@crashtest ~]# vi /etc/phpMyAdmin/config.inc.php

Et renseignons aux lignes 34 et 36 l'utilisateur de contrôle et son mot de passe :

$cfg['Servers'][$i]['controluser']   = 'phpmyadmin';          // MySQL control user settings
                                                    // (this user must have read-only
$cfg['Servers'][$i]['controlpass']   = 'motdepassealeatoire';          // access to the "mysql/user"
                                                    // and "mysql/db" tables).
                                                    // The controluser is also
                                                    // used for all relational
                                                    // features (pmadb)

Une fois le fichier enregistré et déconnecté puis reconnecté à phpMyAdmin, nous pouvons utiliser toutes les possibilités de cet outil !

SELinux

J'avoue ne pas être familier avec SELinux. Je me suis contenté d'éditer /etc/sysconfig/selinux et de passer le paramètre SELINUX à enforcing. Un reboot plus tard, SELinux est activé, httpd, mysqld sont lancés, et phpMyAdmin est accessible !

Installation de phpMyAdmin sur CentOS 6

Nils — Mon, 03 Oct 2011 09:30:00 +0200

Préambule

Il y a un peu plus de deux ans, j'écrivais ce qui reste (à l'écriture de ce billet) le contenu phare de ce blog : installation de phpMyAdmin sur CentOS 5. C'est bien simple, c'est la raison pour laquelle une grande majorité des visiteurs atterrit ici. Ca en devient presque frustrant, d'ailleurs ;-) Bref, toujours est-il que depuis juillet, CentOS 6 est (enfin) disponible , il est donc temps de remettre ce petit tutoriel au goût du jour !

Objectifs : installer et configurer un serveur de base de données MySQL avec une interface web d'administration pour pouvoir ensuite faire du développement ou installer facilement d'autres outils web utilisant ce type de base de données, comme un CMS ou un moteur de blog.

Outils à disposition : que du libre, bien entendu ! Le système d'exploitation est CentOS 6, le serveur de base de données MySQL est disponible dans les dépôts de cette distribution, ainsi que le serveur web, Apache HTTP Server. Le logiciel d'administration web est le très connu phpMyAdmin, qu'on installera (avec ses prérequis) depuis le dépôt EPEL. On supposera donc que la machine a accès à Internet (pour accéder aux dépôts).

Je ne vais pas décrire tout depuis l'installation de l'OS, mais pour s'assurer que les bases sont saines, j'ai effectué une installation ressemblant comme deux gouttes d'eau à mon billet précédent : installation minimaliste d'une CentOS 6 (et je vais peut-être me calmer un peu sur l’auto-promotion ;-) ). Parmi les paramètres importants, notons la désactivation de SELinux.

Une dernière chose avant de rentrer dans le vif du sujet : pour plus de transparence, et aussi parce que les plus intéressés par ce billet sont probablement des débutants dans le monde de GNU/Linux et des logiciels libres, j'ai choisi d'afficher autant que faire se peut les résultats des commandes. Le billet est donc assez long, mais pas complexe pour autant ! Je vous recommande cependant de lire ce billet en entier avant de taper la moindre commande sur votre machine. De toutes façons, vous utilisez une machine (virtuelle) de tests, hein ?

Installation d'Apache, PHP et de phpMyAdmin

Commençons par ajouter le dépôt EPEL à notre installation, de sorte à faciliter l'installation de toute la bande Apache, PHP, MySQL et phpMyAdmin :

[root@crashtest ~]# rpm -ivh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-5.noarch.rpm
Récupération de http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-5.noarch.rpm
attention: /var/tmp/rpm-tmp.c1BYty: Entête V3 RSA/SHA256 Signature, key ID 0608b895: NOKEY
Préparation...                                                          (100%)
1:epel-release                                                         (100%)

Ensuite, c'est assez simple, grâce au jeu des dépendances, nous installons phpMyAdmin :

[root@crashtest ~]# yum install phpmyadmin
Loaded plugins: fastestmirror
Determining fastest mirrors

epel/metalink                                            |  12 kB     00:00     
 * epel: mirrors.ircam.fr

base                                                     | 3.7 kB     00:00     
base/primary_db                                          | 4.2 MB     00:00     

epel                                                     | 4.3 kB     00:00     
epel/primary_db                                          | 3.9 MB     00:15     

extras                                                   |  951 B     00:00     
extras/primary                                           |  203 B     00:00     

updates                                                  | 3.5 kB     00:00     
updates/primary_db                                       | 3.3 MB     00:00     
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package phpMyAdmin.noarch 0:3.4.3.1-1.el6 set to be updated
--> Processing Dependency: php-gd >= 5.2.0 for package: phpMyAdmin-3.4.3.1-1.el6.noarch
--> Processing Dependency: php-mbstring >= 5.2.0 for package: phpMyAdmin-3.4.3.1-1.el6.noarch
--> Processing Dependency: php-mysql >= 5.2.0 for package: phpMyAdmin-3.4.3.1-1.el6.noarch
--> Processing Dependency: php >= 5.2.0 for package: phpMyAdmin-3.4.3.1-1.el6.noarch
--> Processing Dependency: php-mcrypt >= 5.2.0 for package: phpMyAdmin-3.4.3.1-1.el6.noarch
--> Processing Dependency: httpd for package: phpMyAdmin-3.4.3.1-1.el6.noarch
--> Running transaction check
---> Package httpd.x86_64 0:2.2.15-5.el6.centos set to be updated
--> Processing Dependency: httpd-tools = 2.2.15-5.el6.centos for package: httpd-2.2.15-5.el6.centos.x86_64
--> Processing Dependency: /etc/mime.types for package: httpd-2.2.15-5.el6.centos.x86_64
--> Processing Dependency: apr-util-ldap for package: httpd-2.2.15-5.el6.centos.x86_64
--> Processing Dependency: libaprutil-1.so.0()(64bit) for package: httpd-2.2.15-5.el6.centos.x86_64
--> Processing Dependency: libapr-1.so.0()(64bit) for package: httpd-2.2.15-5.el6.centos.x86_64
---> Package php.x86_64 0:5.3.2-6.el6_0.1 set to be updated
--> Processing Dependency: php-cli = 5.3.2-6.el6_0.1 for package: php-5.3.2-6.el6_0.1.x86_64
--> Processing Dependency: php-common = 5.3.2-6.el6_0.1 for package: php-5.3.2-6.el6_0.1.x86_64
---> Package php-gd.x86_64 0:5.3.2-6.el6_0.1 set to be updated
--> Processing Dependency: libpng12.so.0(PNG12_0)(64bit) for package: php-gd-5.3.2-6.el6_0.1.x86_64
--> Processing Dependency: libpng12.so.0()(64bit) for package: php-gd-5.3.2-6.el6_0.1.x86_64
--> Processing Dependency: libjpeg.so.62()(64bit) for package: php-gd-5.3.2-6.el6_0.1.x86_64
--> Processing Dependency: libXpm.so.4()(64bit) for package: php-gd-5.3.2-6.el6_0.1.x86_64
--> Processing Dependency: libfreetype.so.6()(64bit) for package: php-gd-5.3.2-6.el6_0.1.x86_64
--> Processing Dependency: libX11.so.6()(64bit) for package: php-gd-5.3.2-6.el6_0.1.x86_64
---> Package php-mbstring.x86_64 0:5.3.2-6.el6_0.1 set to be updated
---> Package php-mcrypt.x86_64 0:5.3.2-3.el6 set to be updated
--> Processing Dependency: libmcrypt.so.4()(64bit) for package: php-mcrypt-5.3.2-3.el6.x86_64
---> Package php-mysql.x86_64 0:5.3.2-6.el6_0.1 set to be updated
--> Processing Dependency: php-pdo for package: php-mysql-5.3.2-6.el6_0.1.x86_64
--> Running transaction check
---> Package apr.x86_64 0:1.3.9-3.el6_0.1 set to be updated
---> Package apr-util.x86_64 0:1.3.9-3.el6_0.1 set to be updated
---> Package apr-util-ldap.x86_64 0:1.3.9-3.el6_0.1 set to be updated
---> Package freetype.x86_64 0:2.3.11-6.el6_0.2 set to be updated
---> Package httpd-tools.x86_64 0:2.2.15-5.el6.centos set to be updated
---> Package libX11.x86_64 0:1.3-2.el6 set to be updated
--> Processing Dependency: libX11-common = 1.3-2.el6 for package: libX11-1.3-2.el6.x86_64
--> Processing Dependency: libxcb.so.1()(64bit) for package: libX11-1.3-2.el6.x86_64
---> Package libXpm.x86_64 0:3.5.8-2.el6 set to be updated
---> Package libjpeg.x86_64 0:6b-46.el6 set to be updated
---> Package libmcrypt.x86_64 0:2.5.8-9.el6 set to be updated
---> Package libpng.x86_64 2:1.2.44-1.el6 set to be updated
---> Package mailcap.noarch 0:2.1.31-1.1.el6 set to be updated
---> Package php-cli.x86_64 0:5.3.2-6.el6_0.1 set to be updated
---> Package php-common.x86_64 0:5.3.2-6.el6_0.1 set to be updated
---> Package php-pdo.x86_64 0:5.3.2-6.el6_0.1 set to be updated
--> Running transaction check
---> Package libX11-common.noarch 0:1.3-2.el6 set to be updated
---> Package libxcb.x86_64 0:1.5-1.el6 set to be updated
--> Processing Dependency: libXau.so.6()(64bit) for package: libxcb-1.5-1.el6.x86_64
--> Running transaction check
---> Package libXau.x86_64 0:1.0.5-1.el6 set to be updated
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package             Arch         Version                   Repository     Size
================================================================================
Installing:
 phpMyAdmin          noarch       3.4.3.1-1.el6             epel          4.4 M
Installing for dependencies:
 apr                 x86_64       1.3.9-3.el6_0.1           updates       124 k
 apr-util            x86_64       1.3.9-3.el6_0.1           updates        87 k
 apr-util-ldap       x86_64       1.3.9-3.el6_0.1           updates        15 k
 freetype            x86_64       2.3.11-6.el6_0.2          updates       359 k
 httpd               x86_64       2.2.15-5.el6.centos       base          811 k
 httpd-tools         x86_64       2.2.15-5.el6.centos       base           68 k
 libX11              x86_64       1.3-2.el6                 base          582 k
 libX11-common       noarch       1.3-2.el6                 base          188 k
 libXau              x86_64       1.0.5-1.el6               base           22 k
 libXpm              x86_64       3.5.8-2.el6               base           59 k
 libjpeg             x86_64       6b-46.el6                 base          134 k
 libmcrypt           x86_64       2.5.8-9.el6               epel           96 k
 libpng              x86_64       2:1.2.44-1.el6            base          180 k
 libxcb              x86_64       1.5-1.el6                 base          100 k
 mailcap             noarch       2.1.31-1.1.el6            base           27 k
 php                 x86_64       5.3.2-6.el6_0.1           updates       1.1 M
 php-cli             x86_64       5.3.2-6.el6_0.1           updates       2.2 M
 php-common          x86_64       5.3.2-6.el6_0.1           updates       516 k
 php-gd              x86_64       5.3.2-6.el6_0.1           updates       103 k
 php-mbstring        x86_64       5.3.2-6.el6_0.1           updates       504 k
 php-mcrypt          x86_64       5.3.2-3.el6               epel           16 k
 php-mysql           x86_64       5.3.2-6.el6_0.1           updates        75 k
 php-pdo             x86_64       5.3.2-6.el6_0.1           updates        72 k

Transaction Summary
================================================================================
Install      24 Package(s)
Upgrade       0 Package(s)

Total download size: 12 M
Installed size: 42 M
Is this ok [y/N]:

Comme on peut le voir, de nombreux autres logiciels viennent s'installer car phpMyAdmin en a besoin pour fonctionner, comme PHP et Apache HTTPD Server (paquets httpd et apr-*). Appuyons sur la touche y de notre clavier :

Is this ok [y/N]: y
Downloading Packages:

(1/24): apr-1.3.9-3.el6_0.1.x86_64.rpm                   | 124 kB     00:00     

(2/24): apr-util-1.3.9-3.el6_0.1.x86_64.rpm              |  87 kB     00:00     

(3/24): apr-util-ldap-1.3.9-3.el6_0.1.x86_64.rpm         |  15 kB     00:00     

(4/24): freetype-2.3.11-6.el6_0.2.x86_64.rpm             | 359 kB     00:00     

(5/24): httpd-2.2.15-5.el6.centos.x86_64.rpm             | 811 kB     00:00     

(6/24): httpd-tools-2.2.15-5.el6.centos.x86_64.rpm       |  68 kB     00:00     

(7/24): libX11-1.3-2.el6.x86_64.rpm                      | 582 kB     00:00     

(8/24): libX11-common-1.3-2.el6.noarch.rpm               | 188 kB     00:00     

(9/24): libXau-1.0.5-1.el6.x86_64.rpm                    |  22 kB     00:00     

(10/24): libXpm-3.5.8-2.el6.x86_64.rpm                   |  59 kB     00:00     

(11/24): libjpeg-6b-46.el6.x86_64.rpm                    | 134 kB     00:00

(12/24): libmcrypt-2.5.8-9.el6.x86_64.rpm                |  96 kB     00:00     

(13/24): libpng-1.2.44-1.el6.x86_64.rpm                  | 180 kB     00:00     

(14/24): libxcb-1.5-1.el6.x86_64.rpm                     | 100 kB     00:00     

(15/24): mailcap-2.1.31-1.1.el6.noarch.rpm               |  27 kB     00:00     

(16/24): php-5.3.2-6.el6_0.1.x86_64.rpm                  | 1.1 MB     00:00     

(17/24): php-cli-5.3.2-6.el6_0.1.x86_64.rpm              | 2.2 MB     00:00     

(18/24): php-common-5.3.2-6.el6_0.1.x86_64.rpm           | 516 kB     00:00     

(19/24): php-gd-5.3.2-6.el6_0.1.x86_64.rpm               | 103 kB     00:00     

(20/24): php-mbstring-5.3.2-6.el6_0.1.x86_64.rpm         | 504 kB     00:00     

(21/24): php-mcrypt-5.3.2-3.el6.x86_64.rpm               |  16 kB     00:00     

(22/24): php-mysql-5.3.2-6.el6_0.1.x86_64.rpm            |  75 kB     00:00     

(23/24): php-pdo-5.3.2-6.el6_0.1.x86_64.rpm              |  72 kB     00:00     

(24/24): phpMyAdmin-3.4.3.1-1.el6.noarch.rpm             | 4.4 MB     00:18     
--------------------------------------------------------------------------------
Total                                           574 kB/s |  12 MB     00:20     
warning: rpmts_HdrFromFdno: Header V3 RSA/SHA256 Signature, key ID 0608b895: NOKEY

epel/gpgkey                                              | 3.2 kB     00:00 ... 
Importing GPG key 0x0608B895 "EPEL (6) <epel@fedoraproject.org>" from /etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-6
Is this ok [y/N]:

Autre interrogation intéressante : vous aurez remarqué que tout se déroule grâce à yum, et que nous avons installé un dépôt supplémentaire. Ce dépôt s'identifie via une clé GPG qu'il nous faut importer lors de sa première utilisation. Appuyons-donc sur y et continuons :

Is this ok [y/N]: y
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction

  Installing     : php-common-5.3.2-6.el6_0.1.x86_64                       1/24 

  Installing     : apr-1.3.9-3.el6_0.1.x86_64                              2/24 

  Installing     : apr-util-1.3.9-3.el6_0.1.x86_64                         3/24 

  Installing     : apr-util-ldap-1.3.9-3.el6_0.1.x86_64                    4/24 

  Installing     : httpd-tools-2.2.15-5.el6.centos.x86_64                  5/24 

  Installing     : php-pdo-5.3.2-6.el6_0.1.x86_64                          6/24 

  Installing     : php-mysql-5.3.2-6.el6_0.1.x86_64                        7/24 

  Installing     : php-cli-5.3.2-6.el6_0.1.x86_64                          8/24 

  Installing     : php-mbstring-5.3.2-6.el6_0.1.x86_64                     9/24 

  Installing     : 2:libpng-1.2.44-1.el6.x86_64                           10/24 

  Installing     : freetype-2.3.11-6.el6_0.2.x86_64                       11/24 

  Installing     : libjpeg-6b-46.el6.x86_64                               12/24 

  Installing     : libmcrypt-2.5.8-9.el6.x86_64                           13/24 

  Installing     : libXau-1.0.5-1.el6.x86_64                              14/24 

  Installing     : libxcb-1.5-1.el6.x86_64                                15/24 

  Installing     : mailcap-2.1.31-1.1.el6.noarch                          16/24 

  Installing     : httpd-2.2.15-5.el6.centos.x86_64                       17/24 

  Installing     : php-5.3.2-6.el6_0.1.x86_64                             18/24 

  Installing     : php-mcrypt-5.3.2-3.el6.x86_64                          19/24 

  Installing     : libX11-common-1.3-2.el6.noarch                         20/24 

  Installing     : libX11-1.3-2.el6.x86_64                                21/24 

  Installing     : libXpm-3.5.8-2.el6.x86_64                              22/24 

  Installing     : php-gd-5.3.2-6.el6_0.1.x86_64                          23/24 

  Installing     : phpMyAdmin-3.4.3.1-1.el6.noarch                        24/24 

Installed:
  phpMyAdmin.noarch 0:3.4.3.1-1.el6                                             

Dependency Installed:
  apr.x86_64 0:1.3.9-3.el6_0.1                                                  
  apr-util.x86_64 0:1.3.9-3.el6_0.1                                             
  apr-util-ldap.x86_64 0:1.3.9-3.el6_0.1                                        
  freetype.x86_64 0:2.3.11-6.el6_0.2                                            
  httpd.x86_64 0:2.2.15-5.el6.centos                                            
  httpd-tools.x86_64 0:2.2.15-5.el6.centos                                      
  libX11.x86_64 0:1.3-2.el6                                                     
  libX11-common.noarch 0:1.3-2.el6                                              
  libXau.x86_64 0:1.0.5-1.el6                                                   
  libXpm.x86_64 0:3.5.8-2.el6                                                   
  libjpeg.x86_64 0:6b-46.el6                                                    
  libmcrypt.x86_64 0:2.5.8-9.el6                                                
  libpng.x86_64 2:1.2.44-1.el6                                                  
  libxcb.x86_64 0:1.5-1.el6                                                     
  mailcap.noarch 0:2.1.31-1.1.el6                                               
  php.x86_64 0:5.3.2-6.el6_0.1                                                  
  php-cli.x86_64 0:5.3.2-6.el6_0.1                                              
  php-common.x86_64 0:5.3.2-6.el6_0.1                                           
  php-gd.x86_64 0:5.3.2-6.el6_0.1                                               
  php-mbstring.x86_64 0:5.3.2-6.el6_0.1                                         
  php-mcrypt.x86_64 0:5.3.2-3.el6                                               
  php-mysql.x86_64 0:5.3.2-6.el6_0.1                                            
  php-pdo.x86_64 0:5.3.2-6.el6_0.1                                              

Complete!

Pensons à activer Apache au démarrage de la machine :

[root@crashtest ~]# chkconfig --list httpd
httpd           0:arrêt 1:arrêt 2:arrêt 3:arrêt 4:arrêt 5:arrêt 6:arrêt
[root@crashtest ~]# chkconfig httpd on
[root@crashtest ~]# chkconfig --list httpd
httpd           0:arrêt 1:arrêt 2:marche        3:marche        4:marche        5:marche        6:arrêt

Vous croyez que c'est fini ? Pourtant ce n'est que le début : nous n'avons toujours pas installé MySQL et il faut encore configurer le tout.

Installation et configuration de MySQL

Rien de très compliqué :

[root@crashtest ~]# yum install mysql-server
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * epel: mirrors.ircam.fr
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package mysql-server.x86_64 0:5.1.52-1.el6_0.1 set to be updated
--> Processing Dependency: mysql = 5.1.52-1.el6_0.1 for package: mysql-server-5.1.52-1.el6_0.1.x86_64
--> Processing Dependency: perl-DBI for package: mysql-server-5.1.52-1.el6_0.1.x86_64
--> Processing Dependency: perl-DBD-MySQL for package: mysql-server-5.1.52-1.el6_0.1.x86_64
--> Processing Dependency: perl(DBI) for package: mysql-server-5.1.52-1.el6_0.1.x86_64
--> Running transaction check
---> Package mysql.x86_64 0:5.1.52-1.el6_0.1 set to be updated
---> Package perl-DBD-MySQL.x86_64 0:4.013-3.el6 set to be updated
---> Package perl-DBI.x86_64 0:1.609-4.el6 set to be updated
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package              Arch         Version                  Repository     Size
================================================================================
Installing:
 mysql-server         x86_64       5.1.52-1.el6_0.1         updates       8.1 M
Installing for dependencies:
 mysql                x86_64       5.1.52-1.el6_0.1         updates       889 k
 perl-DBD-MySQL       x86_64       4.013-3.el6              base          134 k
 perl-DBI             x86_64       1.609-4.el6              base          705 k

Transaction Summary
================================================================================
Install       4 Package(s)
Upgrade       0 Package(s)

Total download size: 9.8 M
Installed size: 28 M
Is this ok [y/N]:

Là encore, on nous demande une validation avant d'installer les logiciels.

Is this ok [y/N]: y
Downloading Packages:

(1/4): mysql-5.1.52-1.el6_0.1.x86_64.rpm                 | 889 kB     00:00     

(2/4): mysql-server-5.1.52-1.el6_0.1.x86_64.rpm          | 8.1 MB     00:00     

(3/4): perl-DBD-MySQL-4.013-3.el6.x86_64.rpm             | 134 kB     00:00     

(4/4): perl-DBI-1.609-4.el6.x86_64.rpm                   | 705 kB     00:00     
--------------------------------------------------------------------------------
Total                                           8.4 MB/s | 9.8 MB     00:01     
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction

  Installing     : perl-DBI-1.609-4.el6.x86_64                              1/4 

  Installing     : perl-DBD-MySQL-4.013-3.el6.x86_64                        2/4 

  Installing     : mysql-5.1.52-1.el6_0.1.x86_64                            3/4 

  Installing     : mysql-server-5.1.52-1.el6_0.1.x86_64                     4/4 

Installed:
  mysql-server.x86_64 0:5.1.52-1.el6_0.1                                        

Dependency Installed:
  mysql.x86_64 0:5.1.52-1.el6_0.1      perl-DBD-MySQL.x86_64 0:4.013-3.el6     
  perl-DBI.x86_64 0:1.609-4.el6       

Complete!

Maintenant que MySQL est installé, démarrons-le :

[root@crashtest ~]# service mysqld start
Initialisation de la base de données MySQL :  Installing MySQL system tables...
OK
Filling help tables...
OK

To start mysqld at boot time you have to copy
support-files/mysql.server to the right place for your system

PLEASE REMEMBER TO SET A PASSWORD FOR THE MySQL root USER !
To do so, start the server, then issue the following commands:

/usr/bin/mysqladmin -u root password 'new-password'
/usr/bin/mysqladmin -u root -h crashtest password 'new-password'

Alternatively you can run:
/usr/bin/mysql_secure_installation

which will also give you the option of removing the test
databases and anonymous user created by default.  This is
strongly recommended for production servers.

See the manual for more instructions.

You can start the MySQL daemon with:
cd /usr ; /usr/bin/mysqld_safe &

You can test the MySQL daemon with mysql-test-run.pl
cd /usr/mysql-test ; perl mysql-test-run.pl

Please report any problems with the /usr/bin/mysqlbug script!

[  OK  ]

Démarrage de mysqld :  [  OK  ]

MySQL nous informe donc que sans mot de passe administrateur, c'est un peu la fête du slip et qu'il faut absolument remédier à ça. Soyons donc civilisés, mais pas trop, car pour l'exemple, j'initialise le mot de passe root de MySQL à 'anotherhomepage' (le mot de passe en lui-même ne contient pas les guillemets simples) :

[root@crashtest ~]# /usr/bin/mysqladmin -u root password 'anotherhomepage'
[root@crashtest ~]# /usr/bin/mysqladmin -u root -h crashtest password 'anotherhomepage'

Activons MySQL au démarrage de la machine :

[root@crashtest ~]# chkconfig --list mysqld
mysqld          0:arrêt 1:arrêt 2:arrêt 3:arrêt 4:arrêt 5:arrêt 6:arrêt
[root@crashtest ~]# chkconfig mysqld on
[root@crashtest ~]# chkconfig --list mysqld
mysqld          0:arrêt 1:arrêt 2:marche        3:marche        4:marche        5:marche        6:arrêt

Configurations supplémentaires

Si vous avez effectué une installation identique à celle de mon précédent billet, vous aurez remarqué que le firewall est toujours actif, et que celui-ci n'accepte que du SSH et du SMTP :

[root@crashtest ~]# /etc/init.d/iptables status
Table : filter
Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination         
1    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
2    ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0           
3    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           
4    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:22 
5    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:25 
6    REJECT     all  --  0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited 

Chain FORWARD (policy ACCEPT)
num  target     prot opt source               destination         
1    REJECT     all  --  0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited 

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination

Désactivons-le :

[root@crashtest ~]# /etc/init.d/iptables stop
iptables : Suppression des règles du pare-feu : [  OK  ]

iptables : Configuration des chaînes sur la politique ACCEPT : filter [  OK  ]

iptables : Déchargement des modules : [  OK  ]
[root@crashtest ~]# chkconfig --list iptables
iptables       	0:arrêt	1:arrêt	2:marche	3:marche	4:marche	5:marche	6:arrêt
[root@crashtest ~]# chkconfig iptables off
[root@crashtest ~]# chkconfig --list iptables
iptables       	0:arrêt	1:arrêt	2:arrêt	3:arrêt	4:arrêt	5:arrêt	6:arrêt

Il nous faut aussi effectuer une autre modification : l'autorisation des machines du réseau à accéder à phpMyAdmin. Pour cela il nous faut éditer le fichier /etc/httpd/conf.d/phpMyAdmin.conf avec votre éditeur de texte préféré, ou celui installé par défaut, très probablement vi. Dans ce fichier, nous voyons ceci :

<Directory /usr/share/phpMyAdmin/>
   Order Deny,Allow
   Deny from All
   Allow from 127.0.0.1
   Allow from ::1
</Directory>

<Directory /usr/share/phpMyAdmin/setup/>
   Order Deny,Allow
   Deny from All
   Allow from 127.0.0.1
   Allow from ::1
</Directory>

Deux possibilités : la première, ajoutez votre réseau ou vos machines dans les deux sections Directory après les directives Allow en ajoutant justement une directive de ce type. Par exemple, avec un réseau 10.1.1.0/24, ça donnerait :

Allow from 10.1.1.0/24

Une autre possibilité, bien moins sécurisée mais sans doute plus confortable est de tout autoriser. Dans ce cas, les sections deviennent :

<Directory /usr/share/phpMyAdmin/>
   Order Deny,Allow
   Allow from All
</Directory>

<Directory /usr/share/phpMyAdmin/setup/>
   Order Deny,Allow
   Allow from All
</Directory>

Démarrons à présent le serveur web :

[root@crashtest ~]# service httpd start
Démarrage de httpd : [  OK  ]

Il est à présent possible d'accéder à phpMyAdmin, dans mon cas via l'adresse http://crashtest/phpmyadmin/. Bien entendu, un identifiant et un mot de passe seront demandés. Il s'agit de ceux de MySQL (donc 'root' et 'anotherhomepage' dans mon cas).

On pourrait s'arrêter là. Mais ça serait dommage, pour plusieurs raisons :

l'authentification se fait via HTTP, pas d'interface d'authentification un peu jolie qui utiliserait par exemple un cookie de session;
HTTPS n'est pas activé, et donc le mot de passe se retrouve en clair sur le réseau;
le pare-feu est désactivé, sans autre forme de procès (SELinux aussi, d'ailleurs);
phpMyAdmin dispose de fonctions supplémentaires qu'on peut activer en créant une base de données

Ces points seront abordés dans un prochain billet, bien entendu ;-)

Installation minimaliste d'une CentOS 6

Nils — Mon, 08 Aug 2011 11:51:00 +0200

Suite à un billet précédent sur l'installation d'un domU Enterprise Linux sur un dom0 NetBSD, et à la sortie de CentOS 6.0, j'ai fait quelques essais d'installations de cette distribution.

Il n'y a pas d'énormes différences entre le billet cité et CentOS 6.0, juste quelques surprises. La première est au niveau de l'installation en mode texte, qui perd en possibilités, il n'est par exemple plus possible de personnaliser son partitionnement ou la liste des packages. Il faudra préférer une installation via VNC, qui permet d'afficher l'interface graphique. Les limitations en mémoire de RHEL 6 sont d'ailleurs valable pour CentOS 6, attention donc à attribuer assez de mémoire vive, au moins lors de l'installation, pour obtenir l'interface graphique.

J'ai donc décidé de passer par Kickstart pour quelques installations, et là aussi, il y a quelques changements, comme par exemple certains champs optionnels devenus obligatoires. Voici donc un exemple de kickstart commenté pour une installation minimaliste (mais pas minimale) personnalisée :

# Langue et zone horaire
lang fr_FR
keyboard fr 
timezone --utc Europe/Paris
# J'utilise Xen, donc je shutdown pour modifier le noyau d'installation en pygrub
shutdown
text
# on peut chiffrer le mdp root
rootpw changemonmdprootsvp
# j'autorise quelques services du firewall, la configuration au premier boot mais pas de SELinux par contre 
firewall --service=ssh --service=smtp
firstboot --enable
selinux --disabled
# Configuration du réseau
network --device eth0 --bootproto dhcp
# Paramétrage du disque dur : bootloader et partitionnement. Attention, on efface tout !
bootloader --location=mbr --driveorder=xvda
authconfig --enableshadow --passalgo=sha512
clearpart --all --initlabel --drives=xvda
part /boot --fstype ext3 --size 500 
part swap --size 512 
part / --fstype ext3 --size 5000
part /home --fstype ext3 --size 1200
part /var --fstype ext3 --size 400 --grow
# On fait une installation par le réseau, pensez à modifier ces urls par celles qui vous correspondent
# De plus, les dépôts updates et extras sont ajoutés pour que le système soit à jour dès l'installation
url --url http://monmiroirlocal/pub/CentOS/6/os/x86_64/
repo --name=updates --baseurl=http://monmiroirlocal/pub/CentOS/6/updates/x86_64/
repo --name=extras --baseurl=http://monmiroirlocal/pub/CentOS/6/extras/x86_64/
# C'est là qu'on s'amuse avec la liste des paquets.
# --nobase permet une installation très légère, mais il faut au moins le groupe @Core
# A noter que je refuse l'installation de nombreux firmwares matériels car je suis en VM.
%packages --nobase
@Core
ntp
openssh-clients
wget
vim-enhanced
-b43-openfwwf
-kernel-firmware
-aic94xx-firmware
-atmel-firmware
-bfa-firmware
-ipw2100-firmware
-ipw2200-firmware
-ivtv-firmware
-iwl1000-firmware
-iwl3945-firmware
-iwl4965-firmware
-iwl5000-firmware
-iwl5150-firmware
-iwl6000-firmware
-iwl6050-firmware
-libertas-usb8388
-ql2100-firmware
-ql2200-firmware
-ql23xx-firmware
-ql2400-firmware
-ql2500-firmware
-rt61pci-firmware
-rt73usb-firmware
-xorg-x11-drv-ati-firmware
-zd1211-firmware

# La post-installation me permet de récupérer et d'appliquer des configurations spécifiques
# Très pratique pour déboguer, l'option --log :)
%post --log=/root/postinstall.log
wget http://monmiroirlocal/pub/cfg/c6postinstall/prompt.sh -O /etc/profile.d/prompt.sh
wget http://monmiroirlocal/pub/cfg/c6postinstall/CentOS-Base.repo -O /etc/yum.repos.d/CentOS-Base.repo
wget http://monmiroirlocal/pub/cfg/c6postinstall/ntp.conf -O /etc/ntp.conf
wget http://monmiroirlocal/pub/cfg/c6postinstall/main.cf -O /etc/postfix/main.cf
chkconfig ntpd on
chkconfig postfix on

Avec ce genre d'installation, on tombe à moins de 200 paquets installés :)

Utilisation de nombreux domU en backend fichiers sur un dom0 NetBSD

Nils — Thu, 30 Jun 2011 14:35:00 +0200

Oui, j'utilise des machines virtuelles Xen dans des fichiers. Pas de partition, pas de LVM, non. Un bon vieux fichier qu'on peut effacer sans regrets une fois son domU "jetable" inutile. Pour utiliser ces fichiers, et pour monter des fichiers en tant que disque de manière générale, NetBSD utilise le pilote vnd (4). Et par défaut, il y a 4 fichiers spéciaux vnd. Et lorsqu'on désire lancer 42 machines virtuelles en même temps, chacune ayant besoin d'un fichier vnd pour monter son disque dur, on obient une erreur du genre :

Error: Device 51712 (vbd) could not be connected. Hotplug scripts not working.

Alors on s'affole, on copie-colle le message dans un moteur de recherche bien connu, et on tombe sur ce genre de chose :

How much /dev/vnd*d device do you have ? Maube you need to create more ? e.g.: cd /dev ./MAKEDEV vnd4 vnd5 vnd6 vnd7 vnd8

Donc on applique :

root@arreat:/usr/pkg/etc/xen# cd /dev
root@arreat:/dev# ./MAKEDEV vnd4 vnd5 vnd6 vnd7 vnd8 vnd9 vnd10 vnd11 vnd12 vnd14 vnd15
root@arreat:/dev# cd /usr/pkg/etc/xen
root@arreat:/usr/pkg/etc/xen# xm create vmjetable1 && xm create vmkikoo2 \
&& xm create vmpipeau3 && xm create vmdelire4 && xm create encoreunevmjetable

Maintenant, c'est la RAM qui va commencer à manquer... mais c'est un autre problème ;-)

Installation d'un domU Xen Enterprise Linux sur un dom0 NetBSD

Nils — Mon, 20 Jun 2011 09:30:00 +0200

Ces derniers temps je m'amuse à faire des installations par le réseau d'un peu tout et n'importe quoi. J'utilise principalement l'outil de virtualisation Oracle VirtualBox, mais il m'arrive aussi de faire joujou avec Xen. Avec un hôte (dom0) CentOS 5 (et sans doute toutes les distribution de type "Enterprise Linux" telles que Red Hat Enterprise Linux ou Scientific Linux), il est très facile de créer d'autres machines virtuelles (domU) Xen de même type grâce à la commande "virt-install". Avec un dom0 NetBSD cependant, point de commande de ce type. Voyons donc comment faire.

Sur un système Enterprise Linux 5, il est possible de trouver une image de noyau d'installation (et l'initrd approprié) spécifique à Xen, comme par exemple sur ce miroir pour CentOS 5 64 bits.

Ce qui me paraît étrange, c'est avec Enterprise Linux 6, tout du moins avec Scientific Linux. Le noyau 2.6.32 dispose à priori des pv-ops, mais SL6 dispose d'un noyau et d'un initrd Xen. Peut-être est-ce par soucis de compatibilité de chemins, car les fichiers font la même taille que dans le répertoire pxeboot. D'ailleurs, lors de ma synchronisation rsync avec le miroir officiel Scientific Linux, le répertoire xen n'apparaît pas. Et je n'en ai pas eu besoin :)

Une fois nos images de noyau et d'initrd en main, il nous reste à créer notre fichier de configuration de domU, mon exemple prend comme exemple de disque dur un fichier et une connexion réseau par bridge :

name = "centosexample"
uuid = ""
maxmem = 512
memory = 512
kernel  = "/srv/www/pub/CentOS/5/os/x86_64/images/xen/vmlinuz"
ramdisk = "/srv/www/pub/CentOS/5/os/x86_64/images/xen/initrd.img"
extra = "vnc"
on_poweroff = "destroy"
on_reboot = "restart"
on_crash = "restart"
vfb = [  ]
disk = [ "file:/srv/xen/images/disk/centosexample.img,xvda,w" ]
vif = [ "mac=00:16:3a:e2:12:34,bridge=bridge0" ]

Il est possible de faire l'installation en mode texte en supprimant la ligne "extra", et d'ajouter l'url d'un fichier kickstart dans la directive extra, qui devient donc :

extra = "text ks=http://monserveur/pub/cfg/centos5_x86_64.cfg"

La commande "xm create -c centosexample" vous permet de lancer votre domU et de débuter l'installation. Une fois celle-ci faite et votre domU de nouveau éteint, il suffit de commenter les lignes "kernel" et "ramdisk" et de décommenter la ligne "bootloader". Vous pouvez alors démarrer votre domU sans que le noyau de celui-ci soit sur le disque dur du dom0 :)

Lors de mes tests, je me suis limité au partitionnement par défaut (qui utilise LVM), à un détail près : avec Scientific Linux 6, j'ai imposé ext3 à l'installeur. Une fois l'installation terminée, éteindre son domU (proprement de préférence) et modifier la configuration qui devient :

name = "centosexample"
uuid = ""
maxmem = 512
memory = 512
bootloader = "/usr/pkg/bin/pygrub"
on_poweroff = "destroy"
on_reboot = "restart"
on_crash = "restart"
vfb = [  ]
disk = [ "file:/srv/xen/images/disk/centosexample.img,xvda,w" ]
vif = [ "mac=00:16:3a:e2:12:34,bridge=bridge0" ]

J'ai donc remplacé le noyau et l'initrd d'installation par pygrub, qui me permet de démarrer mon domU sur le noyau et l'initrd installés. De plus, les mises à jour ne nécessitent pas de copier de nouveau le noyau et l'initrd sur le dom0.

Pour finir, si vous souhaitez installer un dom0 NetBSD, je ne peux que vous recommander l'excellent billet de Bsdsx !

Configuration d'une redondance DNS

Nils — Mon, 02 May 2011 09:30:00 +0200

Je suis dans la situation suivante : j'ai une machine exécutant entre autres un serveur DHCP et un serveur DNS, et je souhaite réinstaller cette machine. Problème, si je la réinstalle, le DHCP et le DNS seront indisponibles. Il me faut donc redonder ces deux services pour ne pas perturber les autres machines. Après la redondance DHCP, ce billet aborde la redondance DNS. Ce billet, comme le précédent, n'aborde pas la configuration complète d'un serveur DNS mais détaille les options de configurations liées à la redondance

Une redondance basique dans un LAN est très facile à mettre en œuvre car il n'y a pas besoin de modifier quoi que ce soit chez un registrar. Il faudra cependant ajouter l'adresse IP du second serveur DNS dans la configuration de toutes les machines ayant une adresse IP statique, car celles-ci ne récupèrent pas la liste des serveurs DNS via DHCP. Une redondance DNS se compose généralement d'au moins deux serveurs : un serveur maître et un ou plusieurs serveurs esclaves. Toutes nos futures modifications dans le DNS s'effectueront sur le serveur maître et seront répliquées automatiquement vers le serveur esclave. Dans notre cas, le serveur maître utilise NetBSD 4.0 et le serveur esclave utilise NetBSD 5.1; dans les deux cas, ISC Bind est utilisé dans sa version embarquée avec l'OS, et configuré dans un chroot.

Sur notre serveur maître, configurons nos zones dans le fichier /var/chroot/named/etc/named.conf :

zone "anotherhomepage.loc" IN {
        type master;
        file "anotherhomepage.loc";
        allow-update { none; };
        allow-query { any; };
        allow-transfer { 10.13.37.11; };
};

zone "37.13.10.in-addr.arpa" IN {
        type master;
        file "anotherhomepage.loc.reverse";
        allow-update { none; };
        allow-query { any; };
        allow-transfer { 10.13.37.11; };
};

Remarquons que nous autorisons le transfert vers 10.13.37.11 qui est le serveur esclave. Continuons dans le fichier de zone anotherhomepage.loc dont voici quelques extraits :

$TTL 86400
@       IN      SOA     ns0.anotherhomepage.loc. nils.anotherhomepage.loc. (
               2011042601 ; Serial
               8H   ; Refresh
               2H   ; Retry
               4W  ; Expire
               1D  ; Minimum TTL
)

; Name servers
anotherhomepage.loc.    IN      NS     ns0
anotherhomepage.loc.    IN      NS     ns1
; Mail servers
anotherhomepage.loc.    IN      MX      10      mail
; "A" entries
ns0                  IN      A       10.13.37.10
ns1                  IN      A       10.13.37.11
mail                 IN      A       10.13.37.12

Notre serveur esclave est donc renseigné pour le DNS, voyons voir dans le DNS inverse, fichier de zone anotherhomepage.loc.reverse :

$TTL 86400
@       IN      SOA     ns0.anotherhomepage.loc. nils.anotherhomepage.loc. (
               2011042601  ; Serial
               8H   ; Refresh
               2H   ; Retry
               4W  ; Expire
               1D  ; Minimum TTL
)
        IN      NS      ns0.anotherhomepage.loc.
        IN      NS      ns1.anotherhomepage.loc.
        IN      MX      10      mail.anotherhomepage.loc.
10      IN      PTR     ns0.anotherhomepage.loc.
11      IN      PTR     ns1.anotherhomepage.loc.
12      IN      PTR     mail.anotherhomepage.loc.

Occupons-nous à présent de notre serveur esclave. De ce côté, un seul fichier à modifier, /var/chroot/named/etc/named.conf, car les autres seront transférés par les mises à jour de zone :

zone "anotherhomepage.loc" IN {
        type slave;
        masters { 10.13.37.5; };
        file "anotherhomepage.loc";
        allow-update { 10.13.37.5; };
        allow-query { any; };
        allow-notify { 10.13.37.5; };
};

zone "37.13.10.in-addr.arpa" IN {
        type slave;
        masters { 10.13.37.10; };
        file "anotherhomepage.loc.reverse";
        allow-update { 10.13.37.10; };
        allow-query { any; };
        allow-notify { 10.13.37.10; };
};

Il ne reste maintenant qu'à vérifier notre configuration. Par défaut, les logs vont dans /var/log/messages. Vous pouvez définir un autre emplacement pour les logs, comme par exemple :

logging {
        channel simple_log {
                file "/var/log/named/bind.log" ;
                severity info;
                print-time yes;
                print-severity yes;
                print-category yes;
        };
        category default{
                simple_log;
        };
        category queries{
                simple_log;
        };
};

Cet exemple est à insérer dans votre named.conf. Incrémentons les numéros de série, effectuons une relance de bind sur le serveur esclave puis le serveur maître :

root@ns0:/var/chroot/named/var# /etc/rc.d/named reload
Reloading named config files.

Regardons le résultat sur le serveur esclave pour la relance du serveur maître :

root@ns1:/var/chroot/named/etc# tail -f /var/chroot/named/var/log/named/bind.log
26-Apr-2011 19:14:10.864 notify: info: client 10.13.37.5#64893: received notify for zone '37.13.10.in-addr.arpa'
26-Apr-2011 19:14:10.923 general: info: zone 37.13.10.in-addr.arpa/IN: Transfer started.
26-Apr-2011 19:14:10.924 xfer-in: info: transfer of '37.13.10.in-addr.arpa/IN' from 10.13.37.5#53: connected using 10.13.37.60#65525
26-Apr-2011 19:14:11.335 general: info: zone 37.13.10.in-addr.arpa/IN: transferred serial 2011042601
26-Apr-2011 19:14:11.336 xfer-in: info: transfer of '37.13.10.in-addr.arpa/IN' from 10.13.37.5#53: Transfer completed: 1 messages, 258 records, 8672 bytes, 0.411 secs (21099 bytes/sec)
27-Apr-2011 19:14:11.337 notify: info: zone 37.13.10.in-addr.arpa/IN: sending notifies (serial 2011042601)
26-Apr-2011 19:14:11.383 notify: info: client 10.13.37.5#64893: received notify for zone 'anotherhomepage.loc'
26-Apr-2011 19:14:11.388 general: info: zone anotherhomepage.loc/IN: Transfer started.
26-Apr-2011 19:14:11.390 xfer-in: info: transfer of 'anotherhomepage.loc/IN' from 10.13.37.5#53: connected using 10.13.37.60#65524
26-Apr-2011 19:14:11.654 general: info: zone anotherhomepage.loc/IN: transferred serial 2011042601
26-Apr-2011 19:14:11.654 xfer-in: info: transfer of 'anotherhomepage.loc/IN' from 10.13.37.5#53: Transfer completed: 1 messages, 268 records, 8464 bytes, 0.263 secs (32182 bytes/sec)
26-Apr-2011 19:14:11.657 notify: info: zone anotherhomepage.loc/IN: sending notifies (serial 2011042601)

Houra ! Les transferts ont eu lieu ! Maintenant, il reste à modifier dans notre serveur DHCP les adresses IP des serveurs DNS. Dans le cas d'ISC DHCP :

option domain-name-servers 10.13.37.10, 10.13.37.11;

Notez que ce billet permet une redondance assez basique, et loin d'être totalement sécurisée : quelqu'un d'assez malin peut, en utilisant une attaque de type Man-in-the-middle peut appliquer des modifications au serveur esclave. Pour les personnes qui aimeraient corriger ce défaut, il faut se tourner vers DNSSEC.

Configuration d'une redondance DHCP

Nils — Mon, 25 Apr 2011 09:30:00 +0200

Ce billet est basé sur l'excellent billet de Paul Heinlein et publié avec son aimable autorisation. Le billet original se trouve ici.

Commençons par jeter un oeil à la configuration actuelle du serveur DHCP, elle ressemble un peu à ceci :

ddns-domainname "anotherhomepage.loc";
ddns-update-style none;
ddns-updates off;
ignore client-updates;
authoritative;
allow unknown-clients;
max-lease-time 3600;
default-lease-time 1800;
subnet 10.13.37.0 netmask 255.255.255.0 {
        pool {
        deny dynamic bootp clients;
        range 10.13.37.200 10.13.37.249;
        option domain-name-servers 10.13.37.5;
        option domain-name "anotherhomepage.loc";
        option routers 10.13.37.254;
        option broadcast-address 10.13.37.255;
group {
use-host-decl-names true ;

# Virtual Machine de tests PXE
host pxemachine {
        hardware ethernet 08:00:27:d3:8f:2d;
        fixed-address 10.13.37.199;
        option host-name "pxemachine";
}
}
}
}

On y trouve un pool, un groupe et une machine dans ce groupe avec une adresse IP fixée grâce à son adresse MAC : n'importe quelle machine se verra attribuer une adresse entre 10.13.37.200 et 10.13.37.249, mais la machine dont l'adresse MAC est 08:00:27:d3:8f:2d se verra attribuer l'IP 10.13.37.199.

Que se passe-t-il si je stoppe le serveur DHCP ? Les clients n'ont plus d'IP, donc plus d'accès au réseau, ce qui peut s'avérer gênant. Recopions la configuration sur l'autre serveur puis modifions celle-ci, qui va maintenant ressembler à ça :

ddns-domainname "anotherhomepage.loc";
ddns-update-style none;
ddns-updates off;
ignore client-updates;
authoritative;
allow unknown-clients;
max-lease-time 3600;
default-lease-time 1800;
failover peer "dhcp-failover" {
        primary; # declare this to be the primary server
        address 10.13.37.5;
        port 647;
        peer address 10.13.37.60;
        peer port 647;
        max-response-delay 30; 
        max-unacked-updates 10; 
        load balance max seconds 3;
        mclt 1800;
        split 128;
}
subnet 10.13.37.0 netmask 255.255.255.0 {
        pool {
        failover peer "dhcp-failover";
        deny dynamic bootp clients;
        range 10.13.37.200 10.13.37.249;
        option domain-name-servers 10.13.37.5;
        option domain-name "anotherhomepage.loc";
        option routers 10.13.37.254;
        option broadcast-address 10.13.37.255;
group {
use-host-decl-names true ;

# Virtual Machine de tests PXE
host pxemachine {
        hardware ethernet 08:00:27:d3:8f:2d;
        fixed-address 10.13.37.199;
        option host-name "pxemachine";
}
}
}
}

Maintenant notre machine est serveur primaire DHCP et communique avec le serveur désigné après peer address. Allons d'ailleurs voir la nouvelle configuration du serveur secondaire :

ddns-domainname "anotherhomepage.loc";
ddns-update-style none;
ddns-updates off;
ignore client-updates;
authoritative;
allow unknown-clients;
max-lease-time 3600;
default-lease-time 1800;
failover peer "dhcp-failover" {
        secondary; # declare this to be the secondary server
        address 10.13.37.60;
        port 647;
        peer address 10.13.37.5;
        peer port 647;
        max-response-delay 30; 
        max-unacked-updates 10; 
        load balance max seconds 3;
        mclt 1800;
        split 128;
}
subnet 10.13.37.0 netmask 255.255.255.0 {
        pool {
        failover peer "dhcp-failover";
        deny dynamic bootp clients;
        range 10.13.37.200 10.13.37.249;
        option domain-name-servers 10.13.37.5;
        option domain-name "anotherhomepage.loc";
        option routers 10.13.37.254;
        option broadcast-address 10.13.37.255;
group {
use-host-decl-names true ;

# Virtual Machine de tests PXE
host pxemachine {
        hardware ethernet 08:00:27:d3:8f:2d;
        fixed-address 10.13.37.199;
        option host-name "pxemachine";
}
}
}
}

A noter que si vous utilisez un pare-feu sur vos machines, il faudra autoriser les ports 647/tcp et 647/udp qui permettent la communication entre les deux serveurs.

Que se passe-t-il au démarrage et arrêt des serveurs ?

Exemple dans les logs du serveur primaire, après ajout de la configuration, le serveur dhcp primaire est nommé master-dhcp et le secondaire slave-dhcp :

Apr 20 22:28:30 master-dhcp dhcpd: Wrote 0 deleted host decls to leases file.
Apr 20 22:28:30 master-dhcp dhcpd: Wrote 0 new dynamic host decls to leases file.
Apr 20 22:28:30 master-dhcp dhcpd: Wrote 53 leases to leases file.
Apr 20 22:28:31 master-dhcp dhcpd: failover peer dhcp-failover: I move from communications-interrupted to startup
Apr 20 22:28:45 master-dhcp dhcpd: failover peer dhcp-failover: I move from startup to communications-interrupted

Démarrons maintenant DHCPD sur le serveur secondaire, et voyons le résultat sur le serveur primaire :

Apr 20 22:30:29 master-dhcp dhcpd: failover peer dhcp-failover: peer moves from normal to normal
Apr 20 22:30:29 master-dhcp dhcpd: failover peer dhcp-failover: I move from communications-interrupted to normal
Apr 20 22:30:29 master-dhcp dhcpd: pool 80c3200 192.168.6/24 total 50  free 26  backup 24  lts -1

Et regardons les logs du serveur secondaire :

Apr 20 22:30:28 slave-dhcp dhcpd: Wrote 0 deleted host decls to leases file.
Apr 20 22:30:29 slave-dhcp dhcpd: Wrote 0 new dynamic host decls to leases file.
Apr 20 22:30:29 slave-dhcp dhcpd: Wrote 50 leases to leases file.
Apr 20 22:30:29 slave-dhcp dhcpd: failover peer dhcp-failover: I move from normal to startup
Apr 20 22:30:29 slave-dhcp dhcpd: failover peer dhcp-failover: peer moves from normal to communications-interrupted
Apr 20 22:30:29 slave-dhcp dhcpd: failover peer dhcp-failover: I move from startup to normal
Apr 20 22:30:29 slave-dhcp dhcpd: failover peer dhcp-failover: peer moves from communications-interrupted to normal
Apr 20 22:30:29 slave-dhcp dhcpd: pool 7f7ffd8a5150 192.168.6/24 total 50  free 26  backup 24  lts 1

Si je stoppe le serveur primaire, on le voit dans les logs du serveur secondaire :

Apr 20 22:32:08 slave-dhcp dhcpd: peer dhcp-failover: disconnected
Apr 20 22:32:08 slave-dhcp dhcpd: failover peer dhcp-failover: I move from normal to communications-interrupted

Et le redémarrage est aussi visible :

Apr 20 22:32:40 slave-dhcp dhcpd: failover peer dhcp-failover: peer moves from normal to normal
Apr 20 22:32:40 slave-dhcp dhcpd: failover peer dhcp-failover: I move from communications-interrupted to normal
Apr 20 22:32:40 slave-dhcp dhcpd: pool 7f7ffd8a5150 192.168.6/24 total 50  free 26  backup 24  lts 1

Pour finir, cette configuration n'est possible que si les deux serveurs DHCP ont la même version d'ISC DHCP. Heureusement (?), de NetBSD 4.0 jusqu'à NetBSD 5.1 inclus, ISC DHCP est toujours en version 3.0.3 ;-)

Effectuer une netinstall de NetBSD 5

Nils — Mon, 18 Apr 2011 09:30:00 +0200

J'avais déjà rédigé un petit tip pour NetBSDfr, mais cette fois-ci je suis allé un peu plus loin : J'ai documenté l'installation par le réseau, incluant un démarrage PXE de NetBSD 5, pour i386 et amd64. Et c'est sur le wiki NetBSDfr que ça se passe.

Faites chauffer les cartes réseau !

configuration basique pour bozohttpd

Nils — Mon, 04 Apr 2011 09:30:00 +0200

NetBSD possède dans ses sets de base quelques logiciels intéressants pour un serveur : un serveur SSH, un serveur DNS, un serveur DHCP, même un serveur TFTP et celui qui m'intéresse plus particulièrement aujourd'hui, un serveur HTTP. Il ne s'agit pas, comme on pourrait s'y attendre, d'Apache HTTP Server, mais de bozohttpd, un serveur web peu connu mais particulièrement léger et à la configuration minimaliste, pour peu que le besoin le soit aussi. D'ailleurs c'est très simple, mon besoin est on ne peut plus simple : je désire créer un miroir local de distributions Linux et NetBSD et je ne souhaite pas y passer des heures à configurer un virtualhost. Autre avantage de bozohttpd dans ce cas précis, comme il est installé par défaut dans le système de base, pas besoin de l'installer. Ca fera toujours un paquet de moins à maintenir.

Une fois passée l'extase du "pas besoin de l'installer, c'est déjà fait", on se met à la recherche d'un fichier de configuration. Après la frustration d'être rentré bredouille, la page d'accueil du logiciel explique très simplement que "it has no configuration file by design". Il faut donc le configurer en le lançant avec différentes options. Un petit grep bien senti permet de voir comment ça va se passer :

root@arreat:~# grep -i http /etc/defaults/rc.conf 
httpd=NO                httpd_flags=""
                        httpd_wwwdir="/var/www"
                        httpd_wwwuser="_httpd"

Il suffit donc de positionner les options dans la directive "httpd_flags" de son rc.conf, et éventuellement de changer "httpd_wwwdir" selon l'emplacement de ses fichiers. D'abord, copions ces options dans notre rc.conf :

root@arreat:~# grep -i http /etc/defaults/rc.conf >> /etc/rc.conf

Ensuite, pour pouvoir lancer bozohttpd, on édite /etc/rc.conf et on passe httpd=NO à httpd=YES. Une fois l'édition terminée, on lance le serveur :

root@arreat:~# /etc/rc.d/httpd start

Par défaut, bozohttpd cherche un fichier index.html dans "httpd_wwwdir", et affiche son numéro de version. Paranoïa oblige, je souhaite enlever le numéro de version, et comme je veux juste mettre à disposition un miroir local de logiciels, je me fiche qu'il n'y ait pas d'index dans les répertoires. Et pour finir, je change le répertoire de base :

httpd=YES
httpd_flags="-X -S 'AHP Intranet'"
httpd_wwwdir="/srv/www"
httpd_wwwuser="_httpd"

L'option "-X" active le directory indexing, en clair, le listage des fichiers. L'option "-S" suivie d'une chaîne de caractère permet de substituer le nom réel du serveur à un nom personnalisé, ici "AHP Intranet". Une fois le service httpd relancé, j'obtiens ma liste de fichiers :-)

En bref, je n'ai pas eu à passer deux heures à configurer un virtual host, ni à retirer des modules, à tuner le nombre de processus. 10 minutes montre en main. Et pour plus d'options, la documentation peut être accédée via man 8 httpd ou sur le site de bozohttpd.

Flasher son BIOS sans DOS ni Windows

Nils — Mon, 28 Mar 2011 09:30:00 +0200

Mettre à jour le BIOS de sa carte mère, voilà une activité qui peut s'avérer exaspérante au possible : par le passé, cela se faisait en utilisant une disquette (voire deux), contenant un système DOS et deux fichiers, l'utilitaire de flashage et l'image du BIOS proprement dite.

Il fallait donc : - disposer d'un lecteur de disquettes en état de marche, ainsi que de disquettes elles-aussi en état de marche; - disposer d'un système d'exploitation DOS ou d'un système Windows, lequel permettait de créer une disquette de démarrage DOS.

Cela doit faire quelques années qu'on ne vend plus d'ordinateurs équipés de lecteur de disquettes, aussi de nombreux constructeurs fournissent des outils fonctionnant directement sous Windows. Problème : la machine dont je souhaite mettre à jour le BIOS ne possède ni lecteur de disquette, ni de Windows, et pour couronner le tout, même pas de lecteur de CD-ROM. Pour la petite histoire, le système d'exploitation de cette machine a été installé grâce à PXE, et j'avais aussi installé un autre en démarrant sur une clé USB.

Il me faut donc trouver un système capable d'exécuter des programmes DOS, et capable d'être démarré depuis le réseau ou une clé USB. Pour la première partie, c'est assez facile et archi-connu, il s'agit de FreeDOS. Pour la deuxième partie, c'est en fait tout aussi facile : FreeDOS est fourni sous forme d'image ISO. Cette image peut être copiée sur clé USB grâce à l'utilitaire UNetbootin. Il suffit, une fois FreeDOS installé sur la clé USB, de copier l'utilitaire de flashage et l'image du BIOS à la racine de cette clé USB.

Le démarrage d'un ordinateur sur clé USB peut s'avérer plus difficile que prévu : il faut s'assurer en regardant dans le BIOS que celui-ci accepte de démarrer sur USB (ce n'est pas le cas de vieilles machines). Il se peut aussi qu'une option sur le type de périphérique USB (ZIP, disque dur, etc...) soit à modifier, ou la taille (fixe, dynamique). Bref, même aujourd'hui, démarrer sur l'USB, ce n'est pas trivial.

Arrive ensuite le menu de démarrage. UNetbootin semble avoir son propre menu, qui m'affiche plusieurs entrées (qui ne mènent à rien), dont une nommée fdos et l'autre nommée freedos. Dans mon cas, c'est la première qui a fonctionné et qui m'a amené à l'écran de démarrage de FreeDOS. Là encore, je ne détaillerai pas les options, cela dépend vraiment de la machine.

Une fois le prompt obtenu, reste à retrouver l'utilitaire de flashage. On remarque que le prompt affiche "A:\>". La clé USB est en fait en C: donc on tape :

A:\> C:
C:\>

On peut lire le contenu du répertoire courant par la commande "dir", comme sous le vieux DOS de Microsoft. On peut donc vérifier que l'utilitaire de flashage est bien présent dans C: et aller vérifier dans les sous-dossiers si besoin. Ensuite, la commande varie selon les outils, mais lancer l'outil via un truc du genre :

outildeflash.exe

ou alors :

outildeflash.exe help

devrait aider à connaître la bonne syntaxe.

Configuration d'OpenSSH

Nils — Mon, 14 Mar 2011 09:30:00 +0100

OpenSSH est un logiciel formidable, tout le monde le sait. Quelque chose que j'aime beaucoup avec ce logiciel, c'est la manière dont son fichier de configuration permet de simplifier certaines opérations. Je vous propose de voir ou de revoir certaines options qu'on peut ajouter à la suite d'un bloc de configuration qu'on stocke généralement dans ~/.ssh/config .

La base

On va configurer l'accès à la machine "testdrive" dont l'adresse IP est 192.168.13.37. Commençons avec les informations de base :

Host testdrive
        HostName 192.168.13.37
        User nils
        Protocol 2
        Port 22
        ServerAliveInterval 5

Lorsque que je taperai la commande "ssh testdrive", OpenSSH me connectera à la machine 192.168.13.37 en tant qu'utilisateur nils, en utilisant la version 2 du protocole SSH, sur le port 22 et vérifiera toutes les 5 secondes si la machine en question est toujours joignable, ce qui peut s'avérer pratique dans certains cas où on peut être déconnecté du réseau pour cause d'inactivité (réseau de téléphonie mobile, proxy...)

Connexion au travers d'un proxy HTTP

ProxyCommand /usr/bin/corkscrew monproxy.lan 3128 %h %p ~/.ssh/proxy_auth

Ici, j'utilise un utilitaire nommé Corkscrew qui me permet de me connecter via un proxy HTTP à mon serveur. Dans mon exemple, le proxy écooute sur le port 3128 et nécessite une authentification, j'ai donc ajouté un fichier proxy_auth contenant les identifiants. Les variables %h et %p désignent l'hôte vers qui se connecter et son port. A noter que la plupart des serveurs proxy qu'on peut trouver sont configurés pour ne pas autoriser les ports autres que les ports HTTP, HTTPS, et éventuellement FTP. Il faudra donc peut-être changer le port d'écoute de notre testdrive, et mettre notre serveur SSH sur le port 80 ou 443. A noter que selon l'organisation qui administre le proxy, cette manière de faire peut être vue comme une violation de la charte informatique du réseau, ou de tout autre règlement intérieur. Ne l'utilisez donc que si vous y êtes autorisés !

Créer un tunnel SOCKS

DynamicForward 1080

Cette option est très pratique si vous ne voulez pas vous casser la tête à créer un tunnel VPN. Une fois cette option ajoutée à la configuration de votre hôte, et la connexion à celui-ci effective, un tunnel SOCKS écoute sur la boucle locale de votre machine, sur le port 1080. Un cas concret d'utilisation est la connexion à vos sites préférés depuis un point d'accès sans fil public, comme une gare : une fois connecté au réseau, on se connecte en SSH à son serveur, puis on modifie les paramètres de proxy de notre navigateur web pour utiliser un proxy SOCKS dont l'adresse est 127.0.0.1 et le port est 1080. Tout le trafic web du navigateur passe ainsi dans la connexion SSH. Si vous faites souvent le va-et-viens dans votre configuration de proxy, Firefox possède une extension nommée FoxyProxy qui vous facilitera l'existence !

Créer un tunnel pour rediriger du trafic

LocalForward 5901 192.168.13.38:5900

Encapsuler un trafic réseau dans SSH est quelque chose de connu, et l'exemple ci-dessus est lui aussi archi-connu : le protocole VNC transite en clair sur le réseau, l'utilisation de SSH permet de chiffrer la transmission entre notre client et notre serveur. On transfère donc le port 5900 de la machine 192.168.13.38 (qui doit être joignable depuis notre machine testdrive) vers le port 5901 local. On lance ensuite notre client VNC en direction la machine localhost sur le port 5901.

Spécifier l'algorithme de chiffrement

Ciphers aes128-cbc

De nombreux algorithmes de chiffrement sont disponibles avec OpenSSH, vous pourrez trouver la liste dans les pages de manuel. Certains processeurs (tels que l'AMD Geode LX ou le VIA C7) savent déchiffrer certains algorithmes, ce qui les rend plus rapide pour ces types d'opérations. Forcer le chiffrement en AES 128 si vous vous connectez à une machine ayant un CPU AMD Geode peut ainsi s'avérer très efficace pour limiter l'utilisation du CPU et alléger la charge.

Ajouter ses sections personnalisées dans Awstats

Nils — Mon, 28 Feb 2011 09:30:00 +0100

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

Nils — Mon, 14 Feb 2011 09:30:00 +0100

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

Logrotate dans pkgsrc : ça marche chez toi ?

Nils — Wed, 09 Feb 2011 09:30:00 +0100

Il y a quelques mois maintenant, je me suis inscrit au projet pkgsrc-wip chez Sourceforge, dans le but de mettre à jour Logrotate. Le résultat est maintenant utilisable : il y a un makefile et des patches, tout ça compile sans accrocs sous NetBSD 5.0.2 et 5.1 (en amd64 du moins), bref de mon côté c'est au poil :)

Je n'ai pas forcément testé intensivement le paquet binaire, donc je lance ce léger appel à tests, si jamais ça intéresse quelqu'un. Comme Le CVS de pkgsrc-wip est actuellement indisponible, vous pouvez télécharger le Makefile et les patches dans une archive ici. Compilez, faites tourner les logs, merci d'avance !

Awstats

Nils — Mon, 31 Jan 2011 09:30:00 +0100

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.