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.

Suite au précédent article qui traitait de l'installation d'un serveur dédié de virtualisation sur CentOS et la mise en place d'une console graphique distante, nous allons maintenant en découvrir rapidement les fonctionnalités et mettre en place un Windows 2003 server.

Lire la suite de #2 : Présentation de la console Virt-Manager et ajout d'une machine virtuelle

Lorsque vous tentez de vous connecter en SSH sur un serveur CentOS, le login peut prendre de trèèès longues secondes, une bonne trentaine au moins, même en réseau local ce qui se révèle très énervant à force.

En fait il faut ouvrir le fichier /etc/ssh/sshd_config sur le serveur et modifier quelques paramètres.

GSSAPIAuthentication no
UseDNS no

Et voilà, le login est maintenant instantané. Très pratique pour Virt-Manager qui utilise une connexion SSH pour joindre KVM !

Les habitués de VMware et compagnie sont habitués à faire tourner des serveurs dédiés à la virtualisation et à utiliser une console graphique depuis une autre machine. KVM, qui est la solution de virtualisation la plus avancée dans le monde Linux et grandement développée par Red Hat, permet de faire cela aussi.

L'objectif de cet article sera de présenter les différentes couches utilisées, ainsi que la mise en place de notre serveur et de sa console distante en environnement CentOS.

Lire la suite de Serveur de virtualisation KVM avec CentOS et console graphique distante : #1 Installation

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.