Diablotins & Démons Web

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

Trust no one !

La plupart des protocoles réseaux utilisés de nos jours n’étant pas cryptés, il est souvent nécessaire de mettre en place un VPN afin de sécuriser certains flux. Pour cet article, nous utiliserons le daemon VPN ‘mpd‘.

Installation du serveur

Il faut tout d’abord installer le port mpd

# cd /usr/ports/net/mpd/ && make install clean

Puis éditer le fichier ‘/etc/rc.conf‘ pour que le daemon soit lancé au démarrage en background (option -b) sans que la console d’administration soit accessible de l’extérieur (option -a)

mpd_flags="-b -a 127.0.0.1"

mpd_enable="YES"

Configuration du serveur

La configuration se situe dans trois fichiers, voici un exemple de configuration pour chacun des fichiers :

# Fichier /usr/local/etc/mpd/mpd.conf
default:
 load vpn1
vpn1:
 new -i ng0 vpn vpn
 # the session value does matter, but I'm not sure why
 set iface session 28800
 # "username" here should match "username" in mpd.secret
 set bundle authname "majinbox"

 set bundle enable compression
 set ccp yes mppc
 set ccp yes mpp-e40
 set ccp yes mpp-e56
 set ccp yes mpp-e128
 # set this to your correct routing information
 set iface route 10.253.6.0/24
 set link yes acfcomp protocomp
 set ipcp yes vjcomp
 set iface disable on-demand
 set iface idle 0
 set link keep-alive 61 753
 set link mtu 1460
 set ccp yes mpp-stateless
 set link no pap
 set link accept chap
 set link enable no-orig-auth
 open

Cette configuration permet d’avoir un lien appellé ‘vpn1‘ pour l’utilisateur ‘majinbox‘. Dans le cas ou le VPN serait utilisé par des clients sous Windows, il est important de commenter la ligne qui active la compression. Il est possible de créer plusieurs connexions, en ajoutant ‘load vpn2‘ dans la section ‘default‘ et en créant une section contenant les directives propres à la sections.

# fichier /usr/local/etc/mpd/mpd.conf
majinbox MonMotDePasseEnClair

Ce fichier contient les identifiant et mot de passes des différents utilisateurs. Les mots de passes étant stockés en clair, il faut limiter au maximum les droits en lecture sur ce fichier.

#fichier /usr/local/etc/mpd/mpd.links
vpn:
 set link type pptp
 set pptp peer 217.174.206.169
 set pptp enable incoming
 set pptp disable originate

Ce fichier permet de définir le sens des connexions VPN, dans notre cas, la connexion est entrante car nous sommes sur le serveur.

Installation et configuration du client

L’installation est la configuration du client est identique à l’exception du fichier ‘mpd.links‘. Il faut être vigilant et lancer le serveur avant le client.

Jusqu’il y a peu de temps, il fallait bidouiller le /etc/make.conf pour utiliser l’option -j de make permettant de paralléliser la compilation d’un port. En plus d’être un hack relativement laids, ce type de bidouille était incompatible avec certains ports. Ce temps là est révolu, il y maintenant une whitelist de ports qui sont d’office compilé avec autant de job en parallèle qu’il y a de cores présents sur la machine. Les ports qui ne sont pas marqué comme compatibles restent compilés sans parallélisation.

Cette fonctionnalité est activée par défaut, pour la désactiver (ce qui n’a d’intérêt que dans des cas très particuliers), il suffit d’ajouter à /etc/make.conf la directive suivante :

DISABLE_MAKE_JOBS=yes

Afin de forcer le nombre de jobs à exécuter en parallèle (option -j de make), il faut utiliser la directive suivante (toujours dans /etc/make.conf) :

MAKE_JOBS_NUMBER=6

Il existe un option pour les kamikazes téméraires qui permet de forcer l’utilisation de cette nouvelle fonctionnalité pour l’ensemble des ports (même pour ceux qui ne sont pas marqués comme compatibles) :

FORCE_MAKE_JOBS=yes

Je vous déconseille néanmoins cette solution. Si le but est de compiler quelques ports qui ne sont pour l’instant pas marqués comme validés, il suffit d’ajouter le fichier Makefile du ou des ports en question et d’y ajouter la directive suivante en dessous des déclarations de dépendances :

MAKE_JOBS_SAFE=yes

Les mainteneurs de ports peuvent aussi marquer leur port comme incompatible avec la directive :

MAKE_JOBS_UNSAFE=yes