Avant de capituler, sachez juste que j’ai testé en long en large et en travers les solutions de synchro outlook<-> egroupware type Funambol (ex Sync4j), Funambol server et blablabli et je ne sais quoi d’autres généralement bien moisi. S’il fallait donner un bilan : Funambol, ça marche, mais ça se limite à remonter des créneaux horaires (pas des participants, pas de pièce jointe etc). Les autres solutions, ça vaut pas un cachou. Et du Zimbra etc, c’est finalement à peine moins cher qu’un Exchange, chiffres à l’appui.

Voilà, maintenant qu’on ne peut plus m’accuser d’avoir déserté sans livrer bataille, je vous livre 2/3 remarques sur le fonctionnement d’Outlook 2003 et 2007, vis-à-vis d’Exchange et d’une intégration d’un Exchange dans un environnement Linux, notamment un DNS Linux (BIND9 en l’occurrence).

Petite intro

Ces cons de clients mail fonctionnent différemment et Exchange 2007 conserve les deux modes d’accès (pour compatibilité) à certains types de données, notamment aux données disponibilités de chacun pour planifier des réunions facilement. On trouve de la doc sur le sujet, mais c’est pas simple. Et fidèle à lui-même, Microsoft n’a pas cru bon de rendre ses applications bavardes (ie, générer des logs) et à trop vouloir simplifier l’interface utilisateur (même dans un mode de configuration manuelle), certains mécanismes sont complètement occultés et quand ça merde, l’appli ne dit rien !
(Tiens j’oubliais une note positive : en Outlook 2007, l’IMAP est un peu mieux géré : on peut désigner un répertoire d’envoi sans bidouiller comme un malade…)

Imaginons donc le scénario suivant

- un serveur Exchange 2007 dans un domaine (forêt) autonome qui n’est pas le domaine SAMBA « principal » de notre réseau
(- une double maintenance d’utilisateurs dans l’Active Directory et dans l’OpenLDAP (Linux), moyennement quelques scripts, c’est tout à fait vivable.)
- des clients Outlook 2003 et 2007 avec un compte Exchange pour le calendrier et un compte IMAP pour le mail (IMAP hébergé sur Linux)

Imaginons que ça bug après une installation toute fraîche (facile hein ?)

- lorsque je planifie une réunion, je ne vois pas les infos de dispo des gens alors que je peux consulter l’agenda d’un collègue s’il m’autorise (partage)

La solution, après 12000 recherches et forums

- Pour outlook 2003 :
Disons que le serveur ait un FQDN « test.exchg.societe.com ». Le petit « exchq » dans le nom vient du nom du domaine sur lequel est installé Exchange. Donc tous les applicatifs connaissent cette machine sous ce nom complet, et pas « test.societe.com », encore moins « test ».
Manque de bol, lorsque vous déclarez votre compte Exchange dans Outlook, vous spécifiez le serveur « test » et ce tocard vous dit qu’il a trouvé et remplace votre saisie par « test.exchg.societe.com », alors même que votre PC (faisant tourner Outlook) ne sait pas résoudre ce nom complet.
De là, tout marche à peu près *sauf* l’accès aux « public folders » du serveur, donc aux infos de dispo des gens…
Il suffit donc de déclarer ce nom test.exchg dans la zone « societe.com » de votre DNS bind.
Et hop, tout se met à marcher.
Bien sûr, si outlook avait dit dès le départ « cannot find test.exchg.societe.com », j’aurais gagné 2 semaines…

- Pour Outlook 2007 :
Même genre de bordel, sauf que lui, avec un nouveau procédé « autodiscover », veut tout faire tout seul. Même souci : quand il ne trouve pas le serveur comme il le souhaite, il ne dit rien, mais ça marche mal.
Avec une trace tcpdump sur le DNS (genre : tcpdump -i ethxxx port 53 src host mon-ip-PC-client-outlook), et avec l’aide de quelques personnes sur un forum bien sympa, j’ai vu que ce bouffon de client cherchait deux enregistrements DNS :
- l’un de type A pour chercher autodiscover.masociete.com
- l’autre de type SRV, nommé _autodiscover._tcp.masociete.com
Une remarque, pour être sûr de voir la requête lors du tcpdump, videz votre cache DNS du poste client Windows avant :

C:\Documents and Settings\toto>ipconfig /flushdns

Configuration IP de Windows

Cache de résolution DNS vidé.

Enfin, pour régler le problème, vous créerez donc 2 entrées dans votre DNS, zone masociete.com :

autodiscover    A       10.x.y.z ;serveur exchange
_autodiscover._tcp      1D IN SRV 0 1 443       test.exchg ;serveur exchange

Et là, « par magie », vous voyez les infos de dispo des gens lors d’une réservation de réunion.
C’est pas bioutifoule ça ?

Récemment, sur un site web avec une audience non négligeable (sans être démentielle : 70 000 hits hebdo), j’ai eu à mettre en place un outil de statistiques vite fait bien fait. J’ai choisi webalizer car je connaissais et car ça se met en place en 3 minutes et que ça sort mine de rien déjà pas mal d’infos (volume de hits, pays d’origine, mots-clefs, référant etc). Et c’est mieux que « pas de stats du tout » dans un premier temps.

Il y avait deux trucs tout bêtes dans l’histoire : j’avais un an de logs non « synthétisés » par webalizer. Il a donc fallu les faire passer dans webalizer pour rattraper l’historique. Et deuxièmement, c’est à ce moment là que j’ai vu que le HostnameLookups était à Off dans la conf /etc/apache2/apache2.conf. Donc les logs ne contenaient que les IP, pas les hostname. Donc pas de statistiques par pays dans Webalizer. Dommage pour une boîte internationale qui veut voir un peu où en est sa notoriété sur la planète…

J’ai donc remédié à tout ça. Cet article présente donc l’installation de la conf rapide de Webalizer (et Apache2 en conséquence) et donne une ligne de commande pour récupérer l’année d’historique (apache2 garde par défaut 52 fichiers de logs en rotation hebdo) et enfin, le plus marrant, mouliner sur les logs pour retrouver les hostnames correspondants aux IP… (en espérant que mon hébergeur ne me flingue pas en voyant le nombre de requête DNS que je crache en ce moment même Je lui ai posé la question, ne négligez pas ce point, ce serait bête de se faire des ennemis)

Installation et conf Webalizer

Sous Debian, un simple :

aptitude install webalizer

L’outil de conf pose 2/3 questions assez simples à répondre, comme votre nom de serveur web, le nom du fichier « logrotaté », typiquement /var/log/apache2/access.log.1 (et pas /var/log/apache2/access.log).
De toute manière, on va repasser sur le fichier de conf tout de suite après l’install. Sachez que « webalizer » fait ses calculs via la cron.daily, au petit matin (par défaut sur Debian) quand vous dormez.
Je mets 2/3 commentaires sur certains paramètres ; voyons ce que donne egrep -v "^$|^#" /etc/webalizer/webalizer.conf :

LogFile         /var/log/apache2/access.log.1
OutputDir       /var/www/webalizer # A vous de voir. Pensez à un htaccess si besoin...
Incremental     yes
ReportTitle     Statistiques d'utilisation de mon serveur web
HostName        toto.com
TopReferrers    50
TopAgents       30
HideSite        *toto
HideSite        *toto.com
HideReferrer    www.toto.com/ # sinon vous passez votre temps à votre les mouvements interne au site
HideReferrer    toto.com/ # idem
HideReferrer    Direct Request
HideURL         *.gif
HideURL         *.GIF
HideURL         *.jpg
HideURL         *.JPG
HideURL         *.ra
HideURL         *.png
GroupURL        /cgi-bin/*
GroupAgent      MSIE
HideAgent       MSIE*
GroupAgent      Mozilla
HideAgent       Mozilla*
GroupAgent      Lynx
HideAgent       Lynx*
GroupAgent      Konqueror
HideAgent       Konqueror*
GroupAgent      Opera
HideAgent       Opera*
IgnoreSite      localhost # je tunnele l'accès à mon propre site et je suis un gros visiteur de mon propre site
IgnoreReferrer  localhost # idem
MangleAgents    4

Dans la conf Apache2 /etc/apache2/apache2.conf, pensez à activer le paramètre HostnameLookups si vous voulez avoir un semblant de trace des pays rendant visite à votre site web (et rechargez Apache).

Chargement de l’historique

Il faut décompresser les logs Apache puis les importer un à un dans webalizer.Simple.
En considérant que vous avez copié vos fichiers access.log.*.gz dans /tmp, vous faites ceci :

for i in access*gz
do
        gunzip $i
done

Et ensuite, lancement de l’import :

for i in `./seq_reverse.py`
do
        webalizer access.log.$i
done

Je ne sais plus si on peut faire un seq sortant les chiffres de 1 à 52 dans l’ordre inverse, alors j’ai pondu un script python pour le faire.

A la fin, si votre répertoire /var/www/webalizer est blindé de fichiers, c’est bon. Vous pouvez voir vos stats sur l’année écoulée.

Retrouver les hostnames

C’est la partie amusante (et bourrin). Si vous n’aviez pas les hostnames des IP visitant votre serveur web, vos logs Apache ressemblait à ça :

86.x.y.190 - - [15/Mar/2007:06:25:25 +0100] "GET /favicon.ico HTTP/1.1" 200 2238 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2"

Si vous aviez activé le lookup dans Apache, vos logs ressemblent partiellement à ce qu’il y a ci-dessus (pour les serveurs n’ayant pas de nom) et généralement, ils contiennent plutôt ça :

truc.machin.com - - [02/Mar/2008:06:26:27 +0100] "GET / HTTP/1.1" 200 27488 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"

L’idée est de retrouver les noms lorsque vous n’avez que les IP. J’ai écrit un script Python pour ça (excusez-moi, je débute en Python). Script Python pour retrouver les hostnames à partir des IP d’un log Apache2

Et donc à la fin, vous envoyez la purée :

for i in /tmp/access.log.*
do
        ./retrouve_hostname.py $i
done

Attention, c’est bourrin, faites le sur un petit fichier d’abord. Le script vous génère un fichier $i.new, à vous de vider vos statistiques webalizer (rm /var/www/webalizer/*) ensuite et de relancer la moulinette d’import sur ces nouveaux fichiers.

walaaaa, c’est tout pour aujourd’hui.