Archives pour la catégorie ‘Linux’
Sur la machine cible :
# netcat -vv -l -p 7000 | dd of=/dev/hdb listening on [any] 7000 ... connect to [192.168.100.166] from maggie.interact.lu [192.168.100.100] 53106
Sur la machine source :
# dd if=/dev/hdb | netcat -vv 192.168.100.166 7000 Warning: Inverse name lookup failed for `192.168.100.166' 192.168.100.166 7000 (afs3-fileserver) open
Faites attention aux dernières versions d’udev car depuis la version 146, la compatibilité avec les noyaux antérieurs aux 2.6.25 est rompue. Si çà n’est pas le cas, le résultat est sans appel : votre système est incapable de booter et un joli « bloc » textuel va surgir prétextant une impossibilité de trouver le root device ! Heureusement, depuis le package udev-146-r1, un message explicite est affiché juste avant le plantage (cf le screenshot), ce qui n’était le cas du précédent … et lors de mon intervention.
On en parle ici : http://bugs.gentoo.org/292833
Quelques astuces pour contrôler votre RAID sw :
# echo check > /sys/block/md3/md/sync_action
# cat /proc/mdstat Personalities : [raid1] md1 : active raid1 sdb1[1] sda1[0] 128384 blocks [2/2] [UU] md3 : active raid1 sdb3[1] sda3[0] 40001728 blocks [2/2] [UU] [============>........] check = 61.9% (24770752/40001728) finish=4.4min speed=57184K/sec md4 : active raid1 sdb4[1] sda4[0] 112157696 blocks [2/2] [UU] unused devices: <none>
Pour lancer une réparation (obligatoire si le volume est dégradé) :
# echo check > /sys/block/md3/md/sync_action
Pour stopper l’une ou l’autre de ces actions :
# echo idle > /sys/block/md3/md/sync_action
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
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
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.
En cas de mise à jour d’une version majeure d’OpenLDAP, voici la procédure à respecter pour reconstruire votre base LDAP.
Etape 1 : export de votre base LDAP :
# /etc/init.d/slurpd stop # /etc/init.d/slapd stop # slapcat -l /root/ldapdump.raw # egrep -v '^entryCSN:' < /root/ldapdump.raw > /root/ldapdump # mv /var/lib/openldap-data/ /root/openldap-data-backup/
Etape 2 : mise à jour et configuration de la nouvelle version d’OpenLDAP.
Etape 3 : import du dump :
# slapadd -l /root/ldapdump # chown <ldap_user>:<ldap_user> /var/lib/openldap-data/* # /etc/init.d/slapd start
Pour utiliser Mailman avec Nginx, il n’y a aucunement besoin d’un serveur externe pour l’exécution CGI. Une configuration adaptée permet de se passer du serveur THTTPD, utilisé dans ce tutorial.
En premier lieu, lisez mon article traitant de l’exécution CGI/Perl sous Nginx et installez y le wrapper. Il reste ensuite à configurer les deux logiciels.
Côté Nginx, toute la difficulté se situe dans le passage des arguments aux scripts CGI. Par ex :
URL : http://127.0.0.1/mailman/listinfo/my_mailing_list
URI pour Mailman : listinfo/my_mailing_list
Le script CGI listinfo est exécuté avec la variable d’environnement PATH_INFO utilisée pour passer les arguments, égale ici à /my_mailing_list. Bref, des rewrites rules bien conçues et une variable spécifique pour le module FastCGI et Mailman peut ensuite fonctionner à 100 % grâce à Nginx.
Voici la directive de l’hôte :
server {
listen 80;
server_name localhost;
root /var/www/localhost/htdocs;
location /mailman/ {
rewrite "^/mailman/$" http://$host/mailman/listinfo;
set $script $fastcgi_script_name;
set $args /;
if ($request_uri ~ "^/mailman/(.[^\/]*){1}(.*)$" ) {
set $script /$1;
set $args $2;
}
fastcgi_pass unix:/tmp/fcgi-perl.sock;
fastcgi_param SCRIPT_FILENAME /usr/lib/mailman/cgi-bin$script;
fastcgi_param PATH_INFO $args;
include fastcgi_params;
}
location /images/mailman/ {
alias /usr/lib/mailman/icons/;
}
eau de Mailman, les scripts CGI doivent être exécutés par l’utilisateur déclaré lors de sa compilation (option –with-cgi-gid du script configure). Si vous ne pouvez pas modifier cette valeur (ce qui est le cas avec une installation d’un package binaire), il faut modifier les droits sur la socket UNIX fcgi-perl.sock et ajouter l’utilisateur au groupe utilisé par Nginx.
Par exemple, sous Gentoo, je fixe le propriétaire de la socket à apache:nginx et j’ajoute l’utilisateur apache (mailman) au groupe nginx :
# ls -l fcgi-perl.sock srw-rw---- 1 apache nginx 0 2009-10-06 11:53 fcgi-perl.sock
Rendez-vous ensuite sur http://127.0.0.1/mailman et cliquez sur une mailing list pour valider la configuration.
