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.

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.

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)

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 

Lien vers l’article

Lien vers l’article

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.

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.

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.

• 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