J'utilise depuis un certain temps maintenant l'excellent catalogue de médias Delicious Library, pour son interface bien léchée et la possibilité de scanner directement les code-barres de mes BD ou DVD avec la webcam de ma machine. Cela dit, j'ai été un peu négligent ces derniers temps, et les médias non scannés s'accumulant, la flemme prend vite le dessus. Jusqu'à ce que je découvre une extraordinaire application de scanning de code-barres sur iPhone, RedLaser. L'application est gratuite, incroyablement rapide pour lire un code (même si l'autofocus de l'iphone 4g aide, il faut bien le reconnaître), et elle permet de scanner des codes à la chaîne.

Pour cela, rien de plus simple : lancez l'application, appuyez sur le petit éclair en bas au milieu, et une fois en mode scan, activez le bouton "multiple" en bas à droite. Une fois vos scans terminés, revenez à la liste des codes scannés, et envoyez-les par mail en utilisant le petit bouton habituel en bas à gauche (le même icône que dans l'application Photos).

Il ne reste qu'à importer tout ça dans Delicious Library. Pour ce faire, enregistrez le fichier raw-barcodes.txt, renommez-le très exactement en Scanned UPCs Log.txt, et il ne reste plus qu'à faire glisser ce fichier sur la fenêtre de Delicious Library, un + apparaîtra sous votre curseur, et il n'y a plus qu'à le laisser travailler.

A titre d'exemple, il m'a fallu environ 10 minutes pour scanner et importer complètement une étagère de 65 DVD. Plus de raisons d'avoir la flemme!

Il y a quelques jours, je commentais le manque de communication d'Oracle sur l'avenir des différents produits Sun. Ca reste flou, mais il semble tout de même qu'ils fourbissent leurs armes, au moins sur un plan commercial, avec ce white paper.

Rien de vraiment nouveau sous le soleil, bien sûr, si ce n'est le souci de présenter une vision cohérente de l'ensemble des solutions anciennement Sun et l'apport de ces solutions aux différentes solutions applicatives d'Oracle. On en reste donc au même point, ce qui manque, ce sont des arguments pour convaincre les décideurs d'installer du Solaris sur du matériel Oracle plus coûteux, et pas du RedHat sur du x86 HP ou IBM ...

Oracle vient de mettre fin à l'accord qui le liait à HP et permettait à ce dernier d'offrir un support Solaris sur sa gamme de serveur x64 Proliant (anciennement Compaq, avant le rachat de ce dernier par HP). Les clients d'HP qui utilisent Solaris sur ces serveurs pourront renouveler leurs contrats pour une durée de 3 ans maximum, et ce, jusqu'au 1er juillet prochain, ce qui amène la fin du support au 30 juin 2013.

De toute évidence, en fermant les vannes au premier fournisseur de serveurs x86 du marché, Oracle souhaite mettre un terme au déploiement de Solaris sur du hardware non-Sun (pardon, non-Oracle, il faut que je m'habitue). En revanche, difficile de savoir si l'objectif est de sortir totalement du marché du x86 pour se recentrer sur le Sparc, ou s'ils souhaitent simplement promouvoir leurs propres boîtes x86, qui restent plus chères que celles d'HP ou IBM à performances égales.

Entre ces éléments, l'absence de roadmap (si l'on excepte ce document assez vague) et une communication à la transparence digne de Raymond lui-même, il est difficile pour les clients Solaris de savoir où le ballon va retomber, et ça ne les incitera certainement pas à rester fidèles à cet OS. Oracle fait décidément une fleur à Linux, même si c'est probablement bien involontaire.

$ getconf PAGESIZE
4096

$ getconf PAGE_SIZE
4096

Lorsqu'on administre un serveur virtualisé sous Xen depuis son Dom0, bon nombre de commandes traditionnelles que l'on peut passer  pour observer l'état du système se réfèrent au Dom0 lui-même, et ne permettent pas d'observer les caractéristiques physiques du serveur lui-même. C'est en particulier vrai pour les commandes affichant l'état de la mémoire (free, vmstat, top, ...).

Pour afficher les caractéristiques du serveur, on va utiliser la commande xm info :

# xm info | egrep "nr|core|socket|memory"
nr_cpus                : 8
nr_nodes               : 1
sockets_per_node       : 1
cores_per_socket       : 4
threads_per_core       : 2
total_memory           : 4085
free_memory            : 1

On observe ici un serveur avec 1 processeur quad-core avec hyper-threading activé, et 4 Go de RAM.

Pour afficher le statut des liens réseaux physiques sous Solaris, on utilise la commande dladm (pour data-link administration) :

# dladm show-dev
e1000g0         link: up        speed: 1000  Mbps       duplex: full
e1000g1         link: up        speed: 1000  Mbps       duplex: full
e1000g2         link: up        speed: 1000  Mbps       duplex: full
e1000g3         link: unknown   speed: 0     Mbps       duplex: half

On rencontre de temps en temps des processus appelés zombis. Rien à voir avec un film de Georges A. Romero, il s'agit d'un phénomène beaucoup plus prosaïque. Quand un processus se termine, pratiquement toutes les ressources associées sont libérées, à l'exception de l'entrée correspondante dans la table des processus de l'OS. La raison en est simple : le processus parent doit pouvoir récupérer le code de retour de son processus fils, on ne peut donc pas tout effacer brutalement.

Typiquement, la suppression de l'entrée dans la table des processus se fait donc au moment où le parent récupère ce code retour, c'est ce qu'on appelle le reaping (the Reaper étant notre Grande Faucheuse). Si le processus parent, pour une raison où pour une autre, ne lit pas ce code, l'entrée reste présente dans la table des processus. Voyons donc à quoi ces zombis ressemblent, et comment s'en débarrasser.

En soit, c'est généralement peu gênant, puisqu'à part l'entrée dans la table des processus, il n'y a plus rien : ni mémoire consommée, ni CPU utilisé. J'y vois cependant deux inconvénients :

• la table des processus a une table limitée (30000 entrées par défaut), et chaque zombi occupe une place, donc si on en génère beaucoup, cela peut devenir problématique sur un système chargé
• le zombi est vraiment, vraiment laid (et en plus il ne sent pas bon)

$ ps -edf | grep defunct
 daniel     7542  7541   0        - ?           0:00 <defunct>
 daniel     7450  7449   0        - ?           0:00 <defunct>
 daniel     7546  7545   0        - ?           0:00 <defunct>
 daniel     7544  7543   0        - ?           0:00 <defunct>

$ ps -ecl | grep Z
 F S    UID   PID  PPID  CLS PRI     ADDR     SZ    WCHAN TTY         TIME CMD
 0 Z  59002  7450  7449    -   0        -      0        - ?           0:00 <defunct>

$ preap 7450
7450: exited with status 0
$ preap 7542
7542: exited with status 0
$ preap 7544
7544: exited with status 0
$ preap 7546
7546: exited with status 0
$ ps -edf | grep defunct
$

$ nohup perl -e "if (fork()>0) {while (1) {sleep 100*100;};};"

Le bonding d'interfaces réseaux sous Linux permet d'agréger plusieurs interfaces physiques en une seule interface virtuelle. Les deux principales raisons d'utiliser ce type de technologie sont d'une part l'augmentation de la bande passante, et d'autre part la redondance, qui permet donc de sécuriser un accès réseau. Cette solution contient notamment une implémentation du protocole 802.3ad de l'IEEE.

Voyons donc les différents types de bonding, comment déclarer une interface réseau en bonding, et les manipulations propres au bonding sur une interface active. Comme pour mes autres articles récents sur Linux, le cas considéré ici est celui d'une RedHat Enterprise Linux (ou plus simplement RHEL).

Différents modes de bonding

Le mode de bonding se définit dans le fichier /etc/modprobe.conf :

alias bond0 bonding
options bond0 miimon=100 mode=1

C'est l'option mode qui détermine le type de bond :

• mode=0 : round-robin (balance-rr) : les paquets sortent alternativement par chaque interface physique disponible
• mode = 1 : actif/backup (active-backup) : une seule interface physique est utilisée, et le bond bascule sur l'autre en cas de perte de lien
• mode = 2 : répartition par MAC (balance-xor) : pour chaque nouvelle MAC de destination, on sélectionne alternativement une interface physique disponible, mais les paquets à destination d'une MAC donnée sortiront toujours par la même interface
• mode = 3 : broadcast (broadcast) : tous les paquets sont transmis sur toutes les interfaces physiques
• mode = 4 : 802.3ad (802.3ad) : agrégation de liens dynamique, nécessite un switch supportant ce protocole
• mode = 5 : répartition de charge en émission (balance-tlb) : la répartition des paquets sortants sur les interfaces physiques se fait en fonction de leur charge réelle (calculée à partir de leur vitesse), mais les paquets entrants arrivent sur l'interface active, l'autre prenant le relais en cas de panne
• mode = 6 : (balance-alb) : identique au mode 5, avec en plus une répartition de charge sur les paquets entrants (basée sur la charge des interfaces), le driver interceptant les requêtes ARP pour envoyer les adresses de différentes interfaces physiques à des pairs différents

Détection d'une panne

• l'état du lien ethernet : avec l'option miimon=XX, on suit l'état du lien MII (media-independent interface), la valeur XX étant l'intervalle de test en millisecondes
• la recherche d'une adresse IP spécifique via le protocole ARP : dans ce cas, le bond essaie d'obtenir l'adresse MAC associée à l'IP spécifiée. On utilise pour cela les options arp_interval=XX où XX est l'intervalle entre 2 tests en millisecondes, et arp_ip_target=XX.XX.XX.XX pour spécifier l'IP à tester, par exemple l'IP de la gateway par défaut.

Déclarer une interface en bonding

# cat ifcfg-bond0
DEVICE=bond0
IPADDR=1.2.3.4
NETMASK=255.255.255.0
ONBOOT=yes
BOOTPROTO=none

On va ensuite attribuer des interfaces physiques à cette interface virtuelle, en modifiant leurs propres fichiers de description :

# cat ifcfg-eth1
DEVICE=eth1
ONBOOT=yes
BOOTPROTO=static
MASTER=bond0
SLAVE=yes

# cat ifcfg-eth2
DEVICE=eth2
ONBOOT=yes
BOOTPROTO=static
MASTER=bond0
SLAVE=yes

Observer une interface en bonding

Une fois l'interface montée, on peut l'observer dans /proc/net/bonding. Les adresses MAC sont anonymisées, mais à ce niveau, on voit les adresse physiques de chaque interface, sachant que le bond en lui-même ne présentera qu'une seule adresse MAC, celle de la première interface physique utilisée. Dans notre cas, il s'agit d'un bond actif/passif (voir ci-dessous pour plus de détails sur les modes) :

cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.2.4 (January 28, 2008)

Bonding Mode: fault-tolerance (active-backup)
Primary Slave: None
Currently Active Slave: eth1
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0

Slave Interface: eth1
MII Status: up
Link Failure Count: 0
Permanent HW addr: 00:24:81:xx:xx:xx

Slave Interface: eth2
MII Status: up
Link Failure Count: 0
Permanent HW addr: 00:24:81:xx:xx:xx

Manipulation du bonding

Il y a deux types de modifications spécifiques réalisables à chaud sur une interface en bonding :

• ajout/suppression d'une interface physique au bond
• changement de l'interface active du bond dans le cas d'un bond actif/passif

Suppression d'une interface physique du bond

# ifenslave -d bond0 eth2
# cat /proc/net/bonding/bond0 | grep Slave
Primary Slave: None
Currently Active Slave: eth1
Slave Interface: eth1

Ajout d'une interface physique au bond

# ifenslave bond0 eth2
# cat /proc/net/bonding/bond0 | grep Slave
Primary Slave: None
Currently Active Slave: eth1
Slave Interface: eth1
Slave Interface: eth2

Changement de l'interface active dans un bond actif/passif

# ifenslave -c bond0 eth2
# cat /proc/net/bonding/bond0 | grep Slave
Primary Slave: None
Currently Active Slave: eth2
Slave Interface: eth1
Slave Interface: eth2

Dans des environnements Solaris, on rencontre de temps à autres des tentatives d'accès à des filesystems automontés qui n'existent pas, typiquement à cause de règles génériques dans une map d'automontage, ou tout simplement pour des accès à l'interface /net.

Jusqu'à Solaris 10, il était virtuellement impossible de déterminer qui était à l'origine d'un tel accès. Avec DTrace, ça devient non seulement possible, mais même franchement simple.

On va pour cela simplement tracer l'ensemble des appels systèmes de type stat, qui sont généralement utilisés dans ce type de situation pour tester l'existence d'un fichier, vérifier ses droits, etc.

Voilà un exemple de requête possible, affichant PID, PPID, nom du processus et l'argument passé à l'appel système, autrement dit le nom du fichier :

# dtrace -n 'syscall::stat*:entry { printf("--- %d --- %d --- %s - %s",pid,ppid,
                                  execname,copyinstr(arg0)); }'
dtrace: description 'syscall::stat*:entry ' matched 5 probes
CPU     ID                    FUNCTION:NAME
  4   4110        stat:entry --- 13973 --- 12099 --- emagent - /var/adm/utmp
  4   4110        stat:entry --- 25122 --- 25107 --- bptm - /etc/resolv.conf
  4   4110        stat:entry --- 25122 --- 25107 --- bptm - /etc/resolv.conf
  4   4110        stat:entry --- 25122 --- 25107 --- bptm - /usr/openv/netbackup/bp.conf
  4   4110        stat:entry --- 25122 --- 25107 --- bptm - /usr/openv/netbackup/bp.conf
^C

Etant donné que le processus responsable de la requête n'existe pas forcément plus de quelques instants, il vaut mieux ne pas se contenter du PID et du nom du processus, on affichera donc également son uid/gid pour savoir à qui il appartient. Et comme tout ça n'est pas forcément très lisible, on peut rajouter un petit grep au bout. Mettons que l'on cherche à tracer les tentatives d'accès à /net/inexistant :

# dtrace -n 'syscall::stat*:entry { printf("pid=%d - uid=%d - gid=%d -- %s -- %s",
                                  pid,uid,gid,execname,copyinstr(arg0)); }' | grep inexistant
dtrace: description 'syscall::stat*:entry ' matched 5 probes
  4   4462      stat64:entry pid=23621 - uid=1111 - gid=1111 -- bash -- /net/inexistant

Et voilà, nous avons un coupable, et même si le processus en lui-même a disparu, on sait au moins qu'on peut chercher du coté du user 1111.

Ayant récemment déployé une infrastructure DNS, j'ai été confronté à quelques serveurs Solaris réalisant des requêtes inattendues, et surtout en grand nombre. Malheureusement, obtenir l'identité des processus réalisant ces requêtes n'est pas simple, et il faut donc ruser quelque peu.

DTrace est d'une aide certaine sur ce sujet, mais même avec cet outil, il n'y a pas de solution directe : la résolution de noms n'est pas un appel système que l'on peut tracer simplement, mais est composée d'appel(s) à des librairies, qui sont nettement plus difficiles à tracer, et surtout actuellement impossibles à tracer en dehors du contexte d'un processus. On ne peut donc pas décider simplement de tracer tous les appels à la libresolv du système, par exemple ...

Pour tracer les appels DNS, j'ai donc utilisé une combinaison de deux outils :

• udpsnoop.d, un script DTrace de Brendan Gregg, l'un des maîtres incontestés de la discipline
• snoop, pour tracer en parallèle les requêtes DNS

L'outil udpsnoop est censé fournir directement la liste des requêtes UDP émises ou reçues par le serveur, en indiquant le processus concerné, ainsi que les machines sources et destinations avec les ports associés.

Hélas, j'ai rapidement découvert que dans le cas des requêtes DNS, les IP ne sont pas correctement identifiées :

# ./udpsnoop.d 
  UID    PID LADDR           LPORT DR RADDR           RPORT  SIZE CMD
    0  23291 4.0.0.0             0 -> 255.255.0.0         9 18446744073709551608 nscd
    0  23291 4.0.0.0             0 -> 255.255.0.0         9 18446744073709551608 nscd
    0  23291 4.0.0.0             0 -> 255.255.0.0         9 18446744073709551608 nscd

C'est donc pour cela que j'utilise snoop en parallèle, avec un filtre permettant de n'afficher que les requêtes m'intéressant, du type :

# snoop -rd e1000g0 host 1.2.3.4 and port 53
1.2.3.100 -> 1.2.3.4 DNS C toto.mondomaine. Internet Addr ?
1.2.3.4 -> 1.2.3.100 DNS R toto.mondomaine. Internet Addr 1.2.3.101

Dans cet exemple, e1000g0 est l'interface de sortie vers le serveur DNS, dont l'IP est 1.2.3.4.

Je peux donc maintenant voir s'afficher de manière synchrone à la fois les requêtes DNS circulant sur le réseau, et les processus générant du trafic UDP. Avec un peu de chance, et surtout s'il n'y a pas trop de trafic, on peut rapidement identifier les processus réalisant ces appels. Notez simplement qu'il y a généralement un petit décalage, chez moi les paquets s'affichent dans snoop avec presque une demi-seconde d'avance sur udpsnoop.

Sauf que ... sauf que dans l'exemple ci-dessus, le seul processus à réaliser des requêtes est le nscd, le cache des services de noms, ce qui est très logique : quand il est actif, la fonctionnalité de requête aux services de noms l'interroge et priorité, et s'il n'a pas l'information, c'est lui qui se charge d'interroger les services concernés. Il nous faut donc le désactiver temporairement :

# svcadm disable name-service-cache

Ceci fait, on peut utiliser udpsnoop correctement et visualiser les noms des processus qui sont réellement à l'origine des demandes, en notant au passage que l'adresse RADDR a ses digits affichés dans l'ordre inverse :

# ./udpsnoop.d 
  UID    PID LADDR           LPORT DR RADDR           RPORT  SIZE CMD
 2099  13973 4.0.0.0             0 -> 255.255.0.0         9 18446744073709551608 emagent
    0   6864 0.0.0.0         32802 -> 100.3.2.1        3207                   71 vxpal
    0   6935 0.0.0.0         32817 -> 100.3.2.1        3207                   71 vxpal
 2099  13973 4.0.0.0             0 -> 255.255.0.0         9 18446744073709551608 emagent
    0   4970 4.0.0.0             0 -> 255.255.0.0         9 18446744073709551608 vmd
    0   4970 4.0.0.0             0 -> 255.255.0.0         9 18446744073709551608 vmd

Et bien entendu, on n'oublie pas à la fin de réactiver le nscd :

# svcadm enable name-service-cache