Administrateur & Développeur système UNIX/Linux

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 :

• pour une requête spécifique :

mysql> SELECT SQL_CACHE id, name FROM customer;

• pour une connexion (session client) :

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

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é :

• désactiver la règle de filtrage, en ajoutant dans le fichier de configuration local.cf :

# bug 2010 spamassassin
score FH_DATE_PAST_20XX 0.0

• corriger manuellement la regex :

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

Exemple de configuration d’un serveur proxy frontal :

location /solr/ {
   proxy_pass http://julius.interact.lu:8080/apache-solr-1.4.0/;
   proxy_set_header   Host             $host;
   proxy_set_header   X-Real-IP        $remote_addr;
   proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
}

Attention à la dernière mise à jour de Dovecot sur Gentoo … le format de log a changé. Si vous utilisez pop-before-smtp, voici les nouvelles expressions régulières à utiliser :

$logtime_pat = '(\w+ \d+ \d+:\d+:\d+)';
$pat = '^[LOGTIME] (?:imap|pop3)-login: Info: Login: .+? rip=[:f]*(\d+\.\d+\.\d+\.\d+),';

Pour masquer un compte utilisateur de la login box de Mac OS (et également du menu de permutation / Fast Switch User), la commande à saisir est la suivante en spécifiant le compte à la fin :

$ sudo defaults write /Library/Preferences/com.apple.loginwindow HiddenUsersList -array-add postgres

Le compte utilisateur masqué reste évidemment toujours actif. Pour masquer l’élément « Autre… » de la login box (en mode liste), c’est cette commande :

$ sudo defaults write /Library/Preferences/com.apple.loginwindow SHOWOTHERUSERS_MANAGED -bool false

Exim gère son spool par des fichiers bases de données, stockés dans /var/spool/exim/db. Sont enregistrés le statut de chaque message envoyé / refusé / bloqué vers les serveurs SMTP externes et locaux, comme par exemple celui du filtre antivirus amavisd-new. En cas de plantage ou surcharge du serveur, l’antivirus peut refuser la soumission de mail. Exim en retour interrompt l’envoi des mails pour la période de retry et des messages de ce type peuvent apparaître dans les journaux  :

2009-11-03 10:19:27 1EjCDp-0045dF-BP == email@my.domain R=amavis  T=amavis defer (-53): retry time not reached for any host

Pour débloquer l’envoi, il faut nettoyer des bases de données grâce à la commande exim_tidydb, supprimant toutes les entrées obsolètes. Ainsi, pour relancer la soumission des mails :

# exim_tidydb -t 7d /var/spool/exim/ retry

Le délai de suppression est fixé à 7 jours, ce qui est suffisant. Pour afficher le contenu d’une base de données, exim_dumpdb vient en renfort :

# exim_dumpdb /var/spool/exim/ retry
03-Nov-2009 15:46:51  03-Nov-2009 16:07:20  03-Nov-2009 16:22:20
 T:cluster12.us.messagelabs.com:216.82.250.35 111 77 Connection refused
28-Oct-2009 11:06:07  29-Oct-2009 11:11:03  29-Oct-2009 17:11:03
 T:example.com:192.0.32.10 110 321 Connection timed out
03-Nov-2009 11:36:24  03-Nov-2009 22:33:54  04-Nov-2009 03:37:39
 R:v@luxe.diplo.de:<info@amcham.lu> -44 12877 SMTP error from remote mail server after RCPT TO:<v@luxe.diplo.de>: host mx1.bund.de [77.87.224.134]: 450 4.7.1 <info@amcham.lu>: Sender address rejected

Pour automatiser ce nettoyage, ces commandes peuvent être placées en exécution journalière :

# exim_tidydb -t 7d /var/spool/exim/ retry
# exim_tidydb -t 7d /var/spool/exim/ misc
# exim_tidydb -t 7d /var/spool/exim/ wait-amavis
# exim_tidydb -t 7d /var/spool/exim/ wait-remote_smtp

Les noms des fichiers doivent correspondre à votre installation, donc au contenu de /var/spool/exim/db.