Diablotins & Démons Web

Vu que la fin du monde pénurie d’adresses IP V4 est pour bientôt, il devient de bon ton de se mettre à l’IPV6. Nous allons donc voir dans cet article comment cela ce passe au niveau de FreeBSD.

Tout d’abord, il faut savoir que la plupart des outils réseaux de base n’acceptent pas par défaut les adresses IPV6, suivant le cas, un flag doit être précisé sur la ligne de commande ou un binaire supplémentaire existe. Voici une petite liste des correspondances IPV4 -> IPV6 :

• ping -> ping6
• traceroute -> traceroute6
• ifconfig -> ifconfig inet6
• nmap -> nmap -6

Il n’y a donc que très peu de changement, juste quelques caractères en plus à taper. Au niveau du /etc/rc.conf, il suffit d’activer l’IPV6 et de préfixer l’ensemble des directives de configuration réseaux par ipv6_, ce qui donne dans le cas du serveur qui héberge ce blog :

ipv6_enable="YES"
ipv6_ifconfig_em0="2001:14c8:500:117:d9ae:cea0:0:a9 prefixlen 96"
ipv6_static_routes="default"
ipv6_route_default="default 2001:14c8:500:117:d9ae:cea0:0:be"

Les changements sont donc mineurs, d’autant plus que contrairement au IPTables de Linux, PF supporte IPV6 nativement, il n’y a donc pas de PF6 (à la manière d’IP6Tables) à installer et configurer pour sécuriser les flux IPV6.

Suite à un article récent d’Ivan Voras indiquant que 2 patchs améliorant sensiblement les performances de ZFS venaient d’être ajouté à la branche 8-STABLE. J’ai passé le NAS dont on cause ici et ici en 8-STABLE : raidz est réparti sur 3 disques reliés à un contrôleur SATA d’entrée de gamme, le pool est actuellement occupé à 50%.

Bien entendu afin de quantifier l’impact des dernier patchs, j’ai fais quelques bench avant (8.1-RELEASE à jour) et après (8-STABLE compilé il y a une semaine). Le protocole de test est assez simple : on lance un iozone avec 5 threads concurrents sur une partition ZFS. Deux cas différents ont été testés : le cas de « petits » fichiers (100 Mo par fichier) : les 1024 Mo de RAM du serveur permettent alors de cacher au moins une partie des fichiers de tests, dans le deuxième cas de test, les fichiers font 1 Go. Pour chaque test, la taille de l’enregistrement était paramétré à 4 Ko, ce qui est volontairement faible et explique les faibles débits sur les lectures / écritures non séquentielles.

« Petits » Fichiers

Dans ce test, la RAM aide à maintenir les performance lors des accès aléatoires et concurrents. Les gains de performances lors des lectures / écritures parallèles sont impressionnants.

« Gros » fichiers

Dans ce test, la RAM aide beaucoup moins, les gains de performance sont plus faibles mais restent quand même appréciables.

Conclusion

Les gains de performances des derniers patchs ZFS sont réellement significatif, la compilation d’une version stable n’étant pas forcement adaptée à toute les situations, certains préférons néanmoins attendre la sortie de la prochaine release pour en profiter.

Vu que le projet FreeBSD Xen avance sans être suffisament stable pour être utilisé au jour le jour, la solution ESXi de VMWare reste une des solutions gratuites les plus adaptées à la virtualisation de serveurs FreeBSD.

Cependant, cette solution peut aussi engendrer certaines instabilités, en particulier sur les machines virtuelles générant beaucoup d’IO. Voici donc quelques astuces pour obtenir le meilleur d’une machine virtuelle avec VMWare ESXi.

• Rester si possible en FreeBSD 7.x : la version 8.0 n’est pour l’instant pas officiellement compatible avec ESXi
• Tuning du /boot/loader.conf afin de garder une horloge relativement fiable (en effet, dans un contexte virtualisé, le processeur virtuel « saute » facilement des ticks qui sont données à une autre machine virtuelle) :

  kern.hz=100

• Tuning du /etc/sysctl.conf afin d’optimiser la partie système de fichier :

  vfs.read_max=256

• Tuning du /etc/rc.local afin d’optimiser les accès aux disques durs virtuels (à adapter en fonction du nombre de disques durs virtuels) :

  camcontrol tags da0 -N 127
  camcontrol negotiate 0:0 -a -W 16 -O 127 -R 160.000

• Enfin, il est recommandé d’installer la version opensource des VMWare Tools disponible via le port /usr/ports/emulators/open-vm-tools-nox11 (Attention, ce port nécessite d’avoir les sources du kernel disponible dans /usr/src)

Un petit article sur un point que je trouve pour le moins mal documenté dans le Handbook : l’utilisation du port série sous FreeBSD.

Il est où mon device ?

La réponse à cette question fait un peu plus de 3 lettres. Contrairement à ce que semble indiquer le handbook sur la page dédié au ports séries. Le device du port série n’est pas forcement /dev/sio0. Sur les cartes mères récentes, c’est en général /dev/cuau0. Afin de rester dans la confusion, il est aussi à noter que la détection de ce device n’apparait dans /var/run/dmesg.boot. La seule solution que j’ai trouvée pour vérifier que le port série a bien été détecté a donc été de lister le contenu de /dev.

Comment je l’utilise ?

Dans le cas le plus fréquent de nos jours : connexion à l’interface de management d’un équipement réseau, la marche à suivre est relativement simple. Il suffit d’utiliser le programme cu (installé par défaut) en précisant le device (option -l) et éventuellement la vitesse (option -s). Pour récupérer, à la vitesse impressionnante de 9600bps, la console d’un équipement connecté sur le premier port série, il faudra donc éxecuter la commande ci-dessous.

 # cu -l /dev/cuau0 -s 9600 

Je viens de publier la deuxième partie de la série d’article sur la conception d’un NAS sous FreeBSD : au menu, l’installation du matériel et le paramétrage de ZFS. Au passage, je vous fait profiter de mon gros coup de gueule sur Materiel.net qui met un mois à livrer du matériel annoncé comme livré avec un délai de 2/3 jours. Cerise, sur le gateau, même avec un mois de retard, ils livrent un boitier incomplet, j’ai donc attendu 10 jours de plus afin d’avoir ma commande. Je vous recommanderai donc les gars de Mini-ITX.com sont spécialisés dans ce type de boitiers et beaucoup plus sérieux. Le pire c’est qu’ils ne sont pas plus cher et livrent plus rapidement que Materiel.net alors qu’ils sont situés au Royaume-Uni.

Lien vers l’article

Je viens de publier la première partie d’une série d’articles qui décriront pas à pas la mise en place d’un filer (serveur de fichier) sous FreeBSD. Le premier article présente les contraintes du projet et explique les différents choix effectués au niveau du matériel. D’autres articles suivront d’ici quelques jours/semaines.

Lien vers l’article

Trouver une alternative à BIND pour un DNS autoritaire n’est pas chose aisée, entre les usines à gaz  comme PowerDNS et les serveur à la licence douteuse comme djbdns, il se dégage quand même NSD. Le challenger accepte les fichiers de zone au format BIND, équipe déjà 3 des root servers, et implémente des fonctionalités avancées comme DNSSEC et IPV6. Il reste cependant limité à une utilisation en tant que NS autoritaire car il ne sait pas effectuer de resolutions récursives.

Comme d’habitude, nous allons commencer par une installation du logiciel par les ports FreeBSD

# cd /usr/ports/dns/nsd
# make install clean

Nous allons continuer avec l’édition du fichier de configuration

# cd /usr/local/etc/nsd/
# cp nsd.conf.sample nsd.conf
# chmod +w nsd.conf
# vi nsd.conf

Le fichier par défaut est relativement bien commenté, j’ai personnellement modifié les lignes suivantes pour avoir un serveur qui n’écoute que sur une des IPs de la box avec un pidfile dans un dossier particulier et j’en ai profité pour ajouter une zone  DNS :

ip-address:  213.251.171.146
pidfile: "/var/run/nsd/nsd.pid"

zone:
name: "majinboo.org"
zonefile: "majinboo.org.zone"
outgoing-interface: 213.251.171.146
notify: 217.174.206.169 NOKEY
provide-xfr: 217.174.206.169 NOKEY

La modification du chemin du pidfile m’a permis de bypasser un bug lors du lancement du démon, il ne faut pas oublier de créer le dossier en question et d’y donner les droits à l’utilisateur bind.

Avant de lancer le démon, il ne reste plus qu’à créer un fichier de zone au format bind, de le compiler en utilisant zonec et d’ajouter nsd_enable= »YES » à la fin du /etc/rc.conf.

Il est possible d’aller plus loin, par exemple en ajouter des clef DNSSEC pour les échanges entre les serveurs primaires et secondaires.

MAJ : La procédure de mise à jour binaire via freebsd-update est toujours accessible, elle est détaillée ici.

Une petite brève pour annoncer la disponibilité de la première bêta de FreeBSD 8.0. Cette mouture est la première déclinée en version « memstick » (pour les architectures i386 et amd64 uniquement). Cette version permet d’utiliser une clef USB en lieu et place de l’habituel CD. Ça pourra être utile pour installer une FreeBSD sur le dernier coupé sport ou les petites citadines à la mode qui n’ont pas de lecteur CD.

Malgré le retard d’une semaine sur cette première bêta, les prochaines bêta et la release date du 31 aout ne sont pas décallées.

Utiliser FreeBSD en domU dans un hyperviseur Xen sera bientôt possible. Cela faisait déjà un moment qu’une page wiki avait été dédiée à ce projet et qu’une petite équipe travaillait dessus. D’après les derniers tests que j’ai pu faire, le domU FreeBSD est beaucoup plus stable, il reste encore quelques bugs et certains reglages kernel inhabituels sont encore nécessaires mais la solution est presque utilisable pour les bidouilleurs ayant un peu de temps à y consacrer. Pour ceux que ça intéresse, Adrian Chadd met à disposition différentes images kernel ici. Une mailling-list a aussi été dédiée à ce projet.

Pour continuer dans la virtualisation, la version 11 du client XenApp vient d’être ajoutée à l’arbre des ports par Thomas Abthorpe (net/citix_xenapp). Ce client permet donc d’éxecuter des applications Windows virtualisées par un serveur citrix XenApp sous FreeBSD. Attention cependant, ce port nécessite l’utilisation de la compatibilité Linux, les points tricky nécessaires à la mise en place de ce port sont disponibles sur cette page wiki.

Le freeze du code source de la version 8 est annoncé pour bientôt. Au menu de cette nouvelle version quelques fonctionalités sympathiques dont entre autres :

• nouvelle implémentation TTY avec enfin le support de l’UTF-8
• jails hiérarchiques : des jails inclus dans d’autres jails pour plus de sécurité
• nouvelle pile USB
• suppression des verrous de la pile réseau
• corrections de bugs sur la pile 802.11
• nouveaux serveurs et clients NFS
• version 13 de ZFS (cf ce lien) qui est déjà disponible en 7.0-STABLE

Avec tout ça, il y a même un planning provisoire :

• 25 juin : code freeze
• 29 juin : 1ère Bêta
• 6 juillet : 2ème Bêta
• 13 juillet : 3ème Bêta
• 27 juillet : 1ère Release Candidate
• 17 août : 2ème Release Candidate
• 31 août : Release