Archives mensuelles : mars 2008

GRUB avec un disque SAS, des SATA et un BIOS un peu pourri

1 réponse

Voici un petit retour d’install-galère. Le but est de rappeler 2/3 arguments de GRUB bien pratiques et de faire remarquer quelques bizarreries du monde PC, dirons-nous.

Récemment, j’ai installé une Ubuntu sur un PC équipé comme suit :
– disque 1 : SAS (Serial-Attached-SCSI) contenant un windows
– disque 2 : SATA vide prévu pour l’Ubuntu
– disques 3 et 4 : 2 HD SATA de données.

Il n’y avait donc qu’un boot XP normal sur le SAS.

Ordre de boot…

Au départ, le BIOS (d’une marque connue qui ne permet rien ou si peu dans son BIOS) pointait sur le SAS puis SATA dans l’ordre de boot.
J’ai choisi de mettre GRUB sur le disque SATA (et ainsi ne pas flinguer le MBR du Windows). Comme ça les OS ignorent presque que l’autre est là et je peux surtout virer un des 2 disques sans devoir réinstaller le MBR de l’un ou de l’autre.

J’ai donc dû inverser l’ordre de boot dans le BIOS. Rien de surprenant jusque là.
Comme on ne peut pas préciser dans ce BIOS quel SATA ou quel SAS doit booter lorsqu’il y en a plusieurs, c’est donc le premier – pas d’autre possibilité.
Ce premier détail – on s’en rend compte après une première install d’Ubuntu sur le SATA où rien ne boote – force à organiser ses disques (mes SATA en l’occurrence) de sorte que l’Ubuntu soit sur le premier SATA. Au départ, dans mon cas, c’était le dernier (je venais de l’ajouter…)

sda, non, sdd, non (hd3,0) non plus… raaaaaah

J’ai fait plusieurs réinstall de la chose et ça ne s’est pas vraiment passé 2 fois pareil au niveau de la détection des disques durs, donc de l’ordre d’apparition, donc de leurs noms, donc de la conf GRUB. Parfois tout marchait tout seul, parfois après install, plus rien ne bootait (ni Ubuntu, ni Windows).
Un conseil donc, avant de lancer l’installation Ubuntu, lorsque vous êtes en liveOS, vous repérez bien le nom de chaque disque via un petit fdisk. Vous le faites avec le BIOS précablé vers le bon disque (mon SATA dans mon cas) :

ubuntu:~$ sudo fdisk -l
Disque /dev/sda: 146.8 Go, 146815737856 octets
255 heads, 63 sectors/track, 17849 cylinders
Units = cylindres of 16065 * 512 = 8225280 bytes
Disk identifier: 0x12345678

Périphérique Amorce    Début         Fin      Blocs    Id  Système
/dev/sda1   *           1       17849   143372061    7  HPFS/NTFS

Disque /dev/sdb: 400.0 Go, 400088457216 octets
255 heads, 63 sectors/track, 48641 cylinders
Units = cylindres of 16065 * 512 = 8225280 bytes
Disk identifier: 0x12345678

Périphérique Amorce    Début         Fin      Blocs    Id  Système
/dev/sdb1   *           1        2432    19535008+  83  Linux
/dev/sdb2            2433        2681     2000092+  82  Linux swap / Solaris
/dev/sdb3            2682       48641   369173700   83  Linux

Disque /dev/sdc: 400.0 Go, 400088457216 octets
255 heads, 63 sectors/track, 48641 cylinders
Units = cylindres of 16065 * 512 = 8225280 bytes
Disk identifier: 0x12345678

Périphérique Amorce    Début         Fin      Blocs    Id  Système
/dev/sdc1               1       48641   390708801    7  HPFS/NTFS

Disque /dev/sdd: 400.0 Go, 400088457216 octets
255 heads, 63 sectors/track, 48641 cylinders
Units = cylindres of 16065 * 512 = 8225280 bytes
Disk identifier: 0x12345678

Périphérique Amorce    Début         Fin      Blocs    Id  Système
/dev/sdd1               1       48641   390708801    7  HPFS/NTFS

Dans le cas ci-dessus, le SAS de 146 Go puis 3 SATA de 400 Go.
Donc Windows = /dev/sda1 et Ubuntu sera = /dev/sdb1

FIXME : Parfois, et je n’arrive pas à l’expliquer, le boot du Live Ubuntu m’a sorti un mode graphique un peu dégradé et l’ordre des disques changeaient…
Au final, je me suis retrouvé avec une conf GRUB mauvaise et pas grand chose ne bootait.

Dans mon cas, la bonne conf est la suivante – je ne prends que la fin du fichier /boot/grub/menu.lst :

## ## End Default Options ##

title           Ubuntu 7.10, kernel 2.6.22-14-generic
root            (hd0,0)
kernel          /boot/vmlinuz-2.6.22-14-generic root=UUID=52f30332-a489-4df5-8305-85c4a1e7dba1 ro quiet splash
initrd          /boot/initrd.img-2.6.22-14-generic
quiet

title           Ubuntu 7.10, kernel 2.6.22-14-generic (recovery mode)
root            (hd0,0)
kernel          /boot/vmlinuz-2.6.22-14-generic root=UUID=52f30332-a489-4df5-8305-85c4a1e7dba1 ro single
initrd          /boot/initrd.img-2.6.22-14-generic

title           Ubuntu 7.10, memtest86+
root            (hd0,0)
kernel          /boot/memtest86+.bin
quiet

### END DEBIAN AUTOMAGIC KERNELS LIST

# This is a divider, added to separate the menu items below from the Debian
# ones.
title           Other operating systems:
root


# This entry automatically added by the Debian installer for a non-linux OS
# on /dev/sda1
title           Windows XP
map             (hd3) (hd0)
map             (hd0) (hd3)
root            (hd3,0)
makeactive
chainloader     +1

Le piège

Si vous avez été attentif, vous avez vu le piège :
Dans GRUB, le linux est vu comme le premier disque : hd0. C’est vrai, à condition de se dire que le BIOS boote (donc détecte ?) d’abord le SATA (donc il compte d’abord les SATA et le SAS est vu alors en 4è).
=> C’est sur cette info que se base GRUB.

Par contre, le disque contenant vraiment l’OS Linux est sdB, donc le deuxième O_o
=> Ce qui veut dire que Ubuntu redétecte l’ordre des disques à sa manière ensuite (disons que je le vois comme ça, tout au moins 🙂

De même pour le Windows, c’est sdA alors qu’il est vu par le BIOS en dernier (4è => hd3 dans GRUB).

Enfin, piège ultime, les lignes « map » qui n’étaient pas là au départ.
Windows ne tolère de booter que s’il est « le premier disque » – ce qui ne veut rien dire et est une limitation complètement débile. Toujours est-il que là, il est vu à un moment donné comme 4è et sans vous le dire, ce con de NTLOADER ne part pas (et ne vous dit rien). GRUB vous dit que ça merdoit puis vous ramène au menu de boot.
La commande « map » sert à modifier virtuellement l’ordre des disques. Ca suffit à blouser Windows. Attention le « root » reste sur hd3 alors qu’on a inversé les disques, c’est pas dynamique à ce niveau là.

=> Le bilan après installation Ubuntu, c’est qu’aucun des menus ne menait à rien…. il a fallu changer la conf GRUB à la volée pour récupérer le linux, tester les paramètres pour booter le windows et enfin écrire la bonne conf dans /boot/grub/menu.lst

Remarque sur les modifs à la volée de GRUB lors du boot

Si GRUB démarre après une install, mais qu’aucun menu ne vous démarre un OS (ils sont simplement listés), n’oubliez pas que vous avez la touche ‘e’ pour éditer une des lignes du menu de choix du boot. Les raccourcis claviers sont expliqués. Vous pourrez donc choisir un root (hdtruc,bidule) qui va bien.
Si vous avez bien en tête la conf en terme de /dev/sdX et l’ordre des disques vu par le BIOS, vous devriez pouvoir faire booter n’importe quoi. Une fois sous le linux qui héberge le fichier de conf de GRUB, vous reportez vos modifs et c’est fini.

spamassassin : RulesDuJour vs sa-update

1 réponse

Si vous utilis[i]ez « RulesDuJour » pour mettre à jour les règles spamassassin de « Rules Emporium »…. quoi ? comment ça qu’est-ce que je raconte ? Lisez le chapitre qui va bien dans ma doc !! Vous n’utilisez pas les règles SARE ? mais vous le triez comment votre spam ?! 😉
Bon, je reprends.

Depuis quelques semaines (mois ?), le programme RulesDuJour végétait. Il n’y a eu aucune communication sur le sujet à part 2/3 infos éparses dans des mailing-lists. J’ai pris le temps de chercher et poser les questions.
Maintenant, je peux affirmer que RulesDuJour n’est plus supporté (mais fonctionne encore à peu près) et un type du projet spamassassin a monté un serveur permettant de mettre à jour les règles SARE depuis l’outil normal de mise à jour de spamassassin, à savoir sa-update.

Le principe pour configurer sa-update afin qu’il aille chercher vos règles SARE est le suivant :
1) Vous supprimez votre « RulesDuJour » quotidien de votre crontab.
2) Gardez quelque part la liste des règles que vous utilisez (noms des fichiers).
3) Supprimez les règles type /etc/spamassassin/7*cf et le répertoire où vous stockiez RulesDuJour.
4) Ensuite, créez un fichier /etc/spamassassin/channels.txt contenant :

updates.spamassassin.org
70_sare_adult.cf.sare.sa-update.dostech.net
70_sare_bayes_poison_nxm.cf.sare.sa-update.dostech.net
70_sare_evilnum0.cf.sare.sa-update.dostech.net
70_sare_evilnum1.cf.sare.sa-update.dostech.net
autre.regle.de.SARE.cf.sare.sa-update.dostech.net
...

et vos autres règles type blabla.cf en suffixant par .sare.sa-update.dostech.net. Vous comprenez le principe ? le serveur dostech s’attend à recevoir des demandes « au format sa-update » et grâce à des noms de machines bidons indiquant en fait le nom du fichier correspondant à la règle que vous cherchez, sa-update trouve son bonheur.
Ne pas oublier la 1ère ligne des updates « normaux » de spamassassin.

Ensuite, vous planifiez une fois par jour le job suivant :

sa-update --allowplugins --channelfile /etc/spamassassin/channels.txt --nogpg /usr/local/bin/sa-compile && /etc/init.d/spamassassin reload

Notez qu’il y a déjà dans votre /etc/cron.daily un update spamassassin. Faut-il le modifier ? bof, c’est de la conf standard, c’est un coup à ce que ça saute au prochain update/upgrade.
La deuxième partie de la commande (&& /etc/init.d/spamassassin reload) n’est utile que si votre spamassassin tourne en tant que « daemon ».

Les nouvelles règles téléchargées iront s’installer dans /var/lib/spamassassin/3.002003.

Astuce of ze day pour générer sans peine (et sans faute de frappe) le fichier channels.txt. En considérant que vos règles SARE actuelles sont dans /etc/spamassassin et se nomment toutes 7*cf, tapez donc ça :

cat updates.spamassassin.org > /etc/spamassassin/channels.txt
for i in 7*cf
do
echo $i.sare.sa-update.dostech.net >> /etc/spamassassin/channels.txt
done

Voilà. Forcez le premier lancement à la main et contrôlez le contenu du répertoire /var/lib/spamassassin/3.002003 et la présence du daemon spamassassin (si vous l’utilisez en « daemon »).

La « doc » qui fait foi est ici : http://daryl.dostech.ca/sa-update/sare/sare-sa-update-howto.txt

Exchange, outlook… dans un monde de serveurs Linux

Laisser un commentaire

Je passe sur les raisons longuement discutées (pendant environ un an) qui nous ont poussés à installer un Exchange pour son calendrier offline (pour les hommes pressés en déplacement), sur un smartphone/outlook (port de la cravate obligatoire), son outil de CRM (cravate et grosse bagnole sont de mises), etc etc. La partie e-mail reste en Linux et la cohabitation des 2 mondes (exchange+imap linux) dans un Outlook se passera honorablement.
Il y aurait tant à dire sur les solutions de contournement qu’on n’a qu’à troller dans les commentaires si vous le souhaitez.

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 ?

Ressusciter de l’historique (Apache) pour Webalizer

4 réponses

Derrière ce titre qui veut tout et rien dire, un besoin réel.

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) Continuer la lecture →

Le support de Nero craint à mort. Vive Handbrake

2 réponses

Récemment, j’ai acheté un Nero 8 en ligne (si si) pour utiliser Nero Recode afin de créer facilement des vidéos au format PS3 depuis mes DVD, ou d’autres sources.
L’interface est bien, l’application multi-threadée etc. Bref, j’étais enthousiaste. Maintenant je n’utilise plus Nero Recode… Continuer la lecture →

Statistiques de greylisting

5 réponses

Pour ceux qui ne connaissent pas, le « Greylisting » est un mécanisme utile et extrêmement simple à mettre en oeuvre pour réduire significativement le nombre de spams en entrée des serveurs de mails, sans même avoir besoin de les analyser. En gros, vous pouvez diviser par 10 vos mails entrants et le boulot de votre spamassassin, du coup.
Magique ? non, logique.
Je vous propose dans cet article un résultat chiffré sur une installation comptant un backup MX, un frontal (qui encaisse les tentatives d’abus etc + analyse virus) relayant enfin à un serveur final (backend) faisant tourner un bon gros spamassassin/SARE des familles avant la distribution du courrier. Le tout pour desservir 150 utilisateurs et/ou boîtes mails environ (sans compter des vieux comptent qui n’existent plus et que les spammeurs doivent avoir encore « en tête »).
La mise en place du greylisting pour postfix est détaillée dans ma doc, il ne manque qu’une indication : démarrer le service postgrey après installation 🙂 Continuer la lecture →