Je continue mes bidouilles sur OpenBSD en machine virtuelle, sous KVM, et c'est lent, lent lent ! Les compilations sont longues, les extractions je n'en parle même pas... à croire qu'il y a un problème avec KVM, en tous cas j'espère que ce n'est pas une lenteur naturelle. Ce n'est pas vraiment gênant sur un serveur, parce qu'une fois démarré ça tourne sans interruption, mais j'imagine la galère sur un desktop.

Je n'avais pas ces soucis avec NetBSD, sur lequel j'ai beaucoup bidouillé en virtuel également. Une petite recherche sur internet m'indique que visiblement il a fallu attendre la version 4.8 voire 4.9 de OpenBSD pour qu'elle soit fonctionnelle sur KVM, c'est donc très récent et peut-être pas encore bien optimisé. L'autre option serait la lenteur naturelle, ce qui est en soit assez inquiétant.

Affaire à suivre, j'ai lancé une enquête (via les salons IRC pour avoir confirmation ou non).

OpenBSD 5.0 est sorti il y a peu de temps, apportant des nouveautés et mises à jour. Ce système relativement petit en comparaison d'autres et discret dans l'actualité est néanmoins l'un des plus importants car on lui doit notamment OpenSSH qui est aujourd'hui utilisé partout. OpenBSD est réputé pour son intransigeance sur la liberté des logiciels et leur sécurité avec notamment des audits de code.

Installation

La phase d'installation est très simple puisqu'on a affaire à un assistant qui pose des questions (en mode texte) auxquelles il faut répondre. Nom d'hôte, réseau, partitionnement... c'est vraiment très rapide et très simple. A la fin on indique aussi les "sets" à récupérer.

Découverte

Réseau

La configuration du réseau est effectuée par l'installeur néanmoins il est intéressant d'y jeter un coup d'œil. Contrairement à NetBSD, qui utilise le rc.conf, OpenBSD fonctionne sur un système de fichiers hostname.interface. Par exemple, pour l'interface re0 on aura /etc/hostname.re0. La passerelle par défaut doit être ajoutée dans /etc/mygate et les DNS dans /etc/resolv.conf.

Daemons

Le fichier /etc/rc.conf est utilisé pour contrôler les daemons. Il fonctionne avec un système de "flags". Par exemple, dhcpd_flags="" provoquera l'activation du daemon dhcpd au démarrage. Si on en veut pas, il faut spécifier dhcpd_flags=NO. Les scripts des différents daemons sont situés dans /etc/rc.d.

Taille

Le système de base, sans les librairies X11, frôle les 500 Mo d'espace disque ce qui peut sembler un peu beaucoup comparé aux 80 Mo de NetBSD. Mais les objectifs ne sont pas les mêmes.

# uname -a
OpenBSD vmbox.my.domain 5.0 GENERIC#53 amd64
# df -h
Filesystem     Size    Used   Avail Capacity  Mounted on
/dev/wd0a     1005M   41.4M    913M     4%    /
/dev/wd0k     13.7G   68.0K   13.1G     0%    /home
/dev/wd0d      2.1G    2.0K    2.0G     0%    /tmp
/dev/wd0f      2.0G    443M    1.4G    23%    /usr
/dev/wd0g     1005M    2.0K    955M     0%    /usr/X11R6
/dev/wd0h      4.4G    9.0M    4.2G     0%    /usr/local
/dev/wd0j      2.0G    2.0K    1.9G     0%    /usr/obj
/dev/wd0i      1.5G    2.0K    1.4G     0%    /usr/src
/dev/wd0e      3.3G    4.0M    3.1G     0%    /var
# free

Packages et ports

Tout comme FreeBSD et NetBSD, OpenBSD dispose de son système de ports permettant d'installer des logiciels tiers. Des packages sont également mis à disposition sur des miroirs HTTP et FTP pour installer sans devoir compiler. On utilise toujours la variable PKG_PATH et l'outil pkg_add. Pas de dépaysement de ce côté.

Pratique

Installer un système et 3 paquets est insuffisant pour en découvrir toutes les fonctionnalités, dans les prochains jours je vais tenter l'installation sur un serveur avec daemon SMTP et IMAP. Cela me permettra de me familiariser avec l'administration.

Xen est un hyperviseur libre et éprouvé très utilisé même si il se fait petit à petit remplacer par KVM (qui est pourtant assez différent). Cet article va détailler l'installation de Xen 4.1 sur NetBSD-5.1.

Il n'est pas nécessaire de disposer d'un processeur supportant les instructions de virtualisation sauf pour Windows. Mais dans ce tutoriel nous ne l'utiliserons pas.

Lire la suite de Xen + NetBSD en Dom0

J'ai un problème récurent avec pkgsrc. Pour bien comprendre le fonctionnement il faut savoir que NetBSD lui-même ne fourni que peu de logiciels. Un daemon SSH, FTP, HTTP... et pour le reste il faut aller piocher dans pkgsrc, l'équivalent des ports de FreeBSD ou de emerge sur Gentoo. Un ensemble de scripts qui va chercher les sources d'un logiciel et les compile ainsi que ses dépendances.

L'ennui est que par deux fois déjà j'ai été confronté à des logiciels qui ne marchent pas. Prenons tout d'abord prosody. La compilation et installation fonctionnent mais le logiciel ne se lance pas, l'erreur suivante s'affiche :

# prosodyctl start

**************************
Prosody was unable to find util.encodings
This package can be obtained in the following ways:

        Windows:      Make sure you have encodings.dll from the Prosody distribution in util/
        GNU/Linux:    Run './configure' and 'make' in the Prosody source directory to build util/encodings.so

util.encodings is required for Prosody to run, so we will now exit.
More help can be found on our website, at http://prosody.im/doc/depends
**************************

La solution est d'ajouter le préfixe LD_LIBRARY_PATH indiquant l'emplacement des librairies :

# LD_LIBRARY_PATH="/usr/pkg/lib" prosodyctl start

Et puisqu'il n'y a pas de script rc.d pour lancer Prosody, en voici un. Il n'est sûrement pas très propre ou pas parfait mais il fonctionne. Il est inspiré de celui fourni sur FreeBSD :

#!/bin/sh
#
# Prosody XMPP Server init script
#

# PROVIDE: prosody
# REQUIRE: LOGIN

$_rc_subr_loaded . /etc/rc.subr

name="prosody"
pidfile="/var/run/prosody.pid"
command="/usr/pkg/bin/prosodyctl"
load_rc_config $name
prosody=${prosody_enable-"NO"}
extra_comands="status"
start_cmd="prosody_cmd start"
stop_cmd="prosody_cmd stop"
restart_cmd="$stop_cmd; $start_cmd"
status_cmd="prosody_cmd status"

prosody_cmd()
{
        if !  /var/run/prosody.pid -f
        then
                touch /var/run/prosody.pid && chown prosody:wheel /var/run/prosody.pid
                LD_LIBRARY_PATH="/usr/pkg/lib" /usr/pkg/bin/prosodyctl $1
        else
                LD_LIBRARY_PATH="/usr/pkg/lib" /usr/pkg/bin/prosodyctl $1
        fi
}

run_rc_command "$1"

Puis ensuite :

# /etc/rc.d/prosody start

J'essaie maintenant de compiler Xen 4.1 mais ça ne passe pas. Il y a une petite modification à faire dans le Makefile pour pouvoir y arriver. Mais les étapes suivantes posent aussi des problèmes. Si je trouve la solution j'écrirais un article pour la décrire. Je viens de m'inscrire à la mailing list des bugs de pkgsrc et lorsqu'elle sera validé je soumettrai des rapports de bugs.

pkgsrc n'est donc pas fiable à 100%. Il y a des logiciels qui ne compilent pas ou ne se lancent pas.

Je me suis lancé dans le processus de mise à jour de mon serveur sous NetBSD. Et ce n'est pas une opération simple. Il faut :

• S'inscrire aux mailing list pour savoir quand une mise à jour est nécessaire
• Récupérer les sources du kernel et du système
• Compiler
• Déployer

Bien entendu on évite de préférence d'avoir des outils de développement ou de compilation sur un serveur. Donc dans mon cas j'utilise une "buildbox", c'est à dire un serveur (sur une autre machine) qui me sert à compiler les logiciels et à les distribuer.

La compilation/installation du kernel se déroule bien puisqu'il suffit d'un simple copier-coller pour l'installer. En revanche pour le système c'est une autre affaire. L'installation se fait via le script build.sh, ce qui est aisé pour un déploiement en local mais un peu moins à distance. Alors il est possible de copier à la main les fichiers, mais on préconise un démarrage en mode "maintenance" de la machine... chose impossible car je n'ai pas d'écran ni de clavier sur le serveur. Il existe probablement des manipulations à faire, voire même la possibilité de les faire sans devoir démarrer en mode maintenance, mais je ne me suis pas encore lancé pour le moment.

L'entretien d'un serveur NetBSD demande donc beaucoup d'attention et de manipulations. On installe d'ordinaire un serveur pour fournir une application, et c'est sur cette dernière que l'on doit se concentrer. Dans mon cas, le système lui-même est un combat de tous les instants, ce qui a peut-être ses avantages au niveau de la personnalisation, mais pas dans le cadre d'une application en entreprise par exemple.

On ne peut que rarement conclure qu'un système est parfait ou mauvais. On peut cependant se faire des opinions, notamment sur les situations où on peut l'utiliser. J'ai plutôt un avis positif sur NetBSD, pour sa robustesse et sa légèreté. Des qualités qui nous montrent que c'est un produit très sérieux fait par des gens sérieux, bien loin des OS extravagants qui demandent 1,5Go de mémoire vive pour pouvoir booter. Cependant je reste réservé quand au déploiement de NetBSD surtout en entreprise. Je le réserverai plutôt pour des cas particuliers comme les machines de faible puissance.

Au fur et à mesure que je l'utilise j'apprends de plus en plus l'utilisation d'outils du monde UNIX comme vi, cat, sh... et m'approche de plus en plus d'une conclusion définitive sur ce système.