Archives pour janvier, 2010
Quelques corrections mineures ont été apportées. Merci à Achim J.Latz et Zanda pour leurs rapports.
Plugin : rc-vacation-0.3.2.tar.gz
Dépôt Git : http://github.com/bhuisgen/rc-vacation
nameserver 8.8.8.8 nameserver 8.8.4.4
Pour géolocaliser votre connexion Internet (au niveau du DSLAM de votre FAI), une commande sympa :
$ curl -s "http://www.geody.com/geoip.php?ip=$(curl -s icanhazip.com)" | sed '/^IP:/!d;s/<[^>][^>]*>//g' IP: XX.XX.XX.XXX Location: Munshausen, Luxembourg (Visual Online S.A.)
Une petite astuce pour obtenir la date d’installation d’un système d’exploitation Linux grâce à la commande dumpe2fs :
# dumpe2fs /dev/sda1 | grep 'created' dumpe2fs 1.41.9 (22-Aug-2009) Filesystem created: Fri Jan 27 23:35:05 2006
Il est également possible d’obtenir la date du dernier et du prochain filecheck :
# dumpe2fs /dev/sda1|grep check dumpe2fs 1.41.9 (22-Aug-2009) Last checked: Sat Nov 21 04:04:03 2009 Next check after: Thu May 20 05:04:03 2010
Le cache de requêtes de MySQL permet d’optimiser le temps d’exécution des requêtes en lecture, à savoir les SELECT. Son efficacité est d’autant plus grande que les requêtes sont fréquentes et les résultats invariants, ce qui est majoritairement le cas pour les sites Web. Son fonctionnement est simple : la sortie texte de la requête et des résultats des requêtes est mise en cache et le serveur les récupère en cas de requête identique (comparaison caractère à caractère). En cas de modification des données, tous les résultats associés aux tables cache sont nettoyés, ce qui entraîne sur le long terme une fragmentation des blocs mémoire du cache.
Pour vérifier que le cache est activé et ses différents paramètres de configuration :
mysql> SHOW VARIABLES LIKE '%query_cache%'; +------------------------------+----------+ | Variable_name | Value | +------------------------------+----------+ | have_query_cache | YES | | query_cache_limit | 1048576 | | query_cache_min_res_unit | 4096 | | query_cache_size | 33554432 | | query_cache_type | ON | | query_cache_wlock_invalidate | OFF | +------------------------------+----------+ 6 rows in set (0.00 sec)
Ainsi, il est parfois utile de désactiver la mise en cache :
mysql> SELECT SQL_CACHE id, name FROM customer;
mysql> SET SESSION query_cache_type = OFF;
Si query_cache_type est fixée à DEMAND (valeur 2), alors la mise en cache est forcée au niveau du serveur (GLOBAL) ou client (SESSION) :
mysql> SET GLOBAL query_cache_type=2; mysql> SET SESSION query_cache_type=2;
Un script de maintenance journalier peut se charger de défragmenter le cache :
mysql> FLUSH QUERY CACHE;
ou encore le vider :
mysql> RESET QUERY CACHE;
Un problème courant sur les serveurs SMTP Postfix avec gestion virtuelle des utilisateurs avec backend MySQL, concerne la présence de nombreux warnings dans le log comme ceci :
Feb 5 03:02:19 srv07 postfix/cleanup[22193]: warning: 7C6E95117E: virtual_alias_maps map lookup problem for user@domain.fr
Pour le corriger, il suffit de corriger la requête SQL des alias mail :
query = SELECT goto FROM alias WHERE address=CONVERT('%s' USING latin1) AND active = '1
Le channel bonding est une technique d’agrégation au niveau 2 de la pile OSI de n liens réseaux physiques en un seul. Son utilité est de permettre une redondance du lien réseau (si une carte réseau grille, les autres assurent la continuité du lien), d’équilibrer la charge réseau, et également d’augmenter la bande passante (si le switch/routeur réseau peut communiquer plus rapidement que les cartes réseaux).
En premier lieu, il faut vérifier que le module de bonding est compilé dans le noyau (rubrique Device Drivers / Network Device Support / Bonding Driver Support). Ensuite, il faut configurer l’interface réseau de bonding. Par exemple, sous Gentoo, pour former l’interface de bonding bond0 avec deux cartes réseaux eth0 et eth1 :
# cat /etc/conf.d/net
slaves_bond0="eth0 eth1"
depend_bond0() {
need net.eth0 net.eth1
}
config_eth0=( "null" )
config_eth1=( "null" )
config_bond0=( "192.168.1.1 netmask 255.255.255.0 broadcast 192.168.1.255" )
routes_bond0=( "default via 192.168.1.254" )
Les 2 interfaces réseaux eth0 et eth1 sont donc déclarées mais sans leur attribuer d’adresse IP, puis l’interface bond0 effectuant le bonding de eth0 et eth1 se voit attribuer l’IP 192.168.1.1. Il n’est pas nécessaire de redémarrer le serveur, mais il faut veiller à ce que le module soit chargé automatiquement au moment du montage de l’interface réseau, en ajoutant un alias dans /etc/modprobe.conf :
alias bond0 bonding options bond0 mode=0 miimon=100
Au niveau des script rc.d, il reste à ajouter les liens symboliques pour le montage automatique au boot :
# cd /etc/init.d # ln -s net.lo net.eth0 # ln -s net.lo net.eth1 # ln -s net.lo net.bond0 # rc-update del net.eth0 # rc-update del net.eth1 # rc-update add net.bond0 default
Reste ensuite à monter l’interface de bonding :
# /etc/init.d/net.bond0 start
La configuration du bonding peut se faire à chaud avec sysfs :
# cd /sys/class/net/bond0/bonding # cat miimon 100 # cat mii_status up # cat use_carrier 1 # echo 250 > /sys/class/net/bond0/bonding/miimon
Autoriser l’accès SSH pour l’utilisateur root n’est pas une solution conseillée mais elle est parfois nécessaire. Pour limiter les risques d’intrusion, il est possible de limiter uniquement les connexions par clés SSH. Ainsi, toutes les connexions par mot de passe seront refusées et au final, les attaques par dictionnaire empêchées. Pour ce faire, il suffit de remplacer :
PermitRootLogin yes
par :
PermitRootLogin without-password
Le port de Java 6 pour les Macs à CPU 32 bits (Intel CoreDuo 2006) est disponible au téléchargement sur cette page :
Les versions de SpamAssassin antérieures à la version 3.2.5 possèdent une règle de filtrage qui marque par défaut tous les messages datés entre 2010 et 2099 comme spam. L’expression régulière fautive est la suivante :
header FH_DATE_PAST_20XX Date =~ /20[1-9][0-9]/ [if-unset: 2006]
De nombreux sites relayent ce problème sans pour autant apporter les solutions possibles et encore moins souligner que les règles de filtrage doivent être mises à jour quotidiennement. A moins d’avoir un souci au niveau de la mise à jour des règles, ce bug aurait donc dû être écarté.
Les solutions possibles pour corriger le bug sont les suivantes, par ordre croissant d’efficacité :
# bug 2010 spamassassin score FH_DATE_PAST_20XX 0.0
header FH_DATE_PAST_20XX Date =~ /20[1-9][0-9]/ [if-unset: 2006]
par :
header FH_DATE_PAST_20XX Date =~ /20[2-9][0-9]/ [if-unset: 2006]
Pour trouver le fichier à modifier :
# pwd
/var/lib/spamassassin/3.002001/updates_spamassassin_org
# grep -R FH_DATE_PAST_20XX *
updates_spamassassin_org/50_scores.cf:score FH_DATE_PAST_20XX 2.075 3.384 3.554 3.188 # n=2
updates_spamassassin_org/72_active.cf:##{ FH_DATE_PAST_20XX
updates_spamassassin_org/72_active.cf:header FH_DATE_PAST_20XX Date =~ /20[1-9][0-9]/ [if-unset: 2006]
updates_spamassassin_org/72_active.cf:describe FH_DATE_PAST_20XX The date is grossly in the future.
updates_spamassassin_org/72_active.cf:##} FH_DATE_PAST_20XX
Toutefois, il faudra prendre rendez-vous pour la corriger à nouveau en 2020 … d’où la dernière solution.
mettre à jour vos règles de filtrage et l’automatiser quotidiennement par une tâche cron (la solution la plus efficace) :
# /usr/bin/sa-update -D channel,dns [3124] dbg: dns: is Net::DNS::Resolver available? yes [3124] dbg: dns: Net::DNS version: 0.66 [3124] dbg: channel: attempting channel updates.spamassassin.org [3124] dbg: channel: update directory /var/lib/spamassassin/3.002001/updates_spamassassin_org [3124] dbg: channel: channel cf file /var/lib/spamassassin/3.002001/updates_spamassassin_org.cf [3124] dbg: channel: channel pre file /var/lib/spamassassin/3.002001/updates_spamassassin_org.pre [3124] dbg: channel: metadata version = 730418 [3124] dbg: dns: 1.2.3.updates.spamassassin.org => 895075, parsed as 895075 [3124] dbg: channel: preparing temp directory for new channel [3124] dbg: dns: is Net::DNS::Resolver available? yes [3124] dbg: dns: Net::DNS version: 0.66 [3124] dbg: channel: reading MIRRORED.BY file [3124] dbg: channel: found mirror http://daryl.dostech.ca/sa-update/asf/ weight=5 [3124] dbg: channel: found mirror http://www.sa-update.pccc.com/ weight=5 [3124] dbg: channel: selected mirror http://daryl.dostech.ca/ sa-update/asf [3124] dbg: channel: populating temp content file gpg: WARNING: unsafe ownership on homedir `/etc/mail/spamassassin/sa-update-keys' [3124] dbg: channel: file verification passed, testing update [3124] dbg: channel: extracting archive [3124] dbg: dns: is Net::DNS::Resolver available? yes [3124] dbg: dns: Net::DNS version: 0.66 [3124] dbg: channel: lint check succeeded, extracting archive to /var/lib/spamassassin/3.00200/updates_spamassassin_org... [3124] dbg: channel: point of no return for existing /var/lib/spamassassin/3.00200/updates_spamassassin_org [3124] dbg: channel: creating MIRRORED.BY file [3124] dbg: channel: creating update cf/pre files [...] [3124] dbg: channel: adding 72_active.cf [...] [3124] dbg: channel: update complete
Si la mise à jour est effective, la regex est corrigée automatiquement :
# pwd
/var/lib/spamassassin/3.002001/updates_spamassassin_org
# grep -R FH_DATE_PAST_20XX *
50_scores.cf:score FH_DATE_PAST_20XX 2.075 3.384 3.554 3.188 # n=2
72_active.cf:##{ FH_DATE_PAST_20XX
72_active.cf:header FH_DATE_PAST_20XX Date =~ /20[2-9][0-9]/ [if-unset: 2006]
72_active.cf:describe FH_DATE_PAST_20XX The date is grossly in the future.
72_active.cf:##} FH_DATE_PAST_20XX
Si elle n’est pas effectuée (et c’était malheureusement mon cas sur un serveur mail), corrigez votre fichier de serveurs miroirs avec les suivants :
# pwd /var/lib/spamassassin/3.002001/updates_spamassassin_org # cat MIRRORED.BY # test mirror: zone, cached via Coral #http://buildbot.spamassassin.org.nyud.net:8090/updatestage/ http://daryl.dostech.ca/sa-update/asf/ weight=5 http://www.sa-update.pccc.com/ weight=5
N’oubliez pas de redémarrer le démon spamd et/ou encore votre logiciel de filtrage mail (amavisd-new, etc).
Source : http://wiki.apache.org/spamassassin/Rules/FH_DATE_PAST_20XX
