Administrateur & Développeur système UNIX/Linux

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 :

http://landonf.bikemonkey.org/static/soylatte/

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;
}

La mise à jour complète du serveur a été effectuée ce 1er janvier 2010.

FreeBSD 8.0-STABLE #0: Fri Jan  1 17:42:57 CET 2010

Pour les propriétaires des derniers MacBook, il y a un joli tour de magie à connaître. Il vous faut pour cela un bracelet à fermeture aimantée ou encore tout autre aimant disposé près de votre poignet gauche… Approchez le comme si vous alliez taper normalement sur le clavier… et tout s’éteint … On enlève hop çà remarche ! Eh oui, la détection de fermeture du capot s’appuie sur un contact aimanté.

Voilà c’est fini ! Tous les serveurs de mon entreprise ont été migrés au nouveau centre d’hébergement. Si la précédente intervention (27/11) a été éprouvante pour ma part avec 12 h non stop (en majorité à cause d’un serveur récalcitrant), aujourd’hui tout s’est déroulé dans les temps (6 h) et sans pépin. Les 9 serveurs concernés par cette intervention ont donc rejoint un rack tout neuf. Il reste encore un serveur à racker en haut, mais rien ne presse pour l’instant. Un grand merci à ma visseuse électrique qui a pu optimiser les temps de montage/démontage.

En prime, quelques photos de la nouvelle installation.

Ayant participé à la migration ezPublish 4 d’un site bancaire luxembourgeois au cours de l’année précédente, mon collègue m’avait reporté un problème concernant l’outil de traduction ezlupdate chargé d’extraire les chaînes à internationaliser. L’outil fourni par eZ à cette époque n’acceptait pas l’extraction de chaînes depuis des fichiers PHP au format UTF-8, alors qu’il le supportait  au niveau des templates.

J’ai donc dû modifier les sources de la version Qt 3 et générer un nouveau parseur. L’outil a rempli son rôle et je vous en fait part : ezlupdate-source-hb-20090217.tar.gz

Pour compiler les sources :

cd /<ezroot>/support
tar czf ezlupdate-source-hb-20090217.tar.gz
cd ezlupdate-HB
qmake ezlupdate.pro
make

N’oubliez pas d’installer Qt 3 et ses outils de développement pour la commande qmake. Pour l’utiliser, il faut ajouter l’option –utf8 pour pouvoir créer le fichier de traduction :

/bin/linux/ezlupdate -e extension/test/ -no eng-GB --utf8

Note : la nouvelle version d’ezlupdate basée sur Qt 4 semble à présent gérer les scripts PHP UTF-8 – quasiment un an après – mais il subsiste des problèmes avec les traductions commentées et les traductions dans les javascripts.

Je viens d’ouvrir un dépôt git public sur github pour mon plugin vacation RoundCube. C’est par ici : http://github.com/bhuisgen/rc-vacation/.

Pour cloner le dépôt, lancez la commande suivante :

$ git clone git://github.com/bhuisgen/rc-vacation.git

Mon intervention nocturne s’est bien passée. Elle avait pour but initial de vérifier l’état de l’installation avant la migration physique qui se déroulera en deux temps, le 28/11 et 5/12.  Le programme de ces 6 heures nocturnes était :

• le redémarrage des 15 serveurs pour validation et anticipation des filecheck forcés.
• la mise à jour et la validation des nouveaux noyaux 2.6 : optimisations, support IPv6 pour certains et correction des problèmes existants liés à grsecurity / udev / smartd. Magique, les claviers USB sont reconnus :)
• la vérification des paramètres BIOS pour permettre le reboot électrique distant.
• le dérackage d’un serveur candidat à une réinstallation OS 64 bits 32 bits de mes deux mains.

Il n’y a pas eu de problème particulier si ce n’est un script iptables généré par Firewall Builder dernier cri, qui ne fonctionne pas sur le nouveau noyau 2.6.28 IPv6 ready (erreur shell sur un test if, à croire que FWB s’est trompé dans l’ordre d’initialisation). Au passage, j’ai encore une fois perdu 30 minutes minimum + 10 km + toutes les contraintes de sécurité liées pour un KVM qui ne fonctionne pas, en précisant que cette fois-ci c’était écran + clavier KO. Le téléphone aussi était KO mais çà je peux le rebooter. Alors un merci chaleureux à ceux qui ont débranché cet accès primordial…

Je vous fait part de quelques photos de l’installation, avant de vous montrer celles du nouveau rack dans les prochaines semaines.