Je tiens tout d'abord à préciser que le contenu de cet article ne représente que mon avis, s'appliquant à mon usage particulier. Mon serveur n'est pas un système critique, l'utilisation est faible, il n'y a pas de données top-secrètes, et pas de contraintes de fonctionnement sans interruption (une coupure de quelques minutes n'est pas critique).

Dans cet article je vais faire part de mes impressions concernant les différents OS que j'ai utilisés sur mon serveur. Il est toujours dur de trancher, de dire "lequel j'aime bien" car je ne souhaite absolument pas sous-entendre qu'il y a des manques ou des défauts sur les autres. Je veux juste souligner une préférence, ce qui est encore une fois un critère subjectif dépendant de l'utilisation.

Rappel

Je dispose d'un serveur chez moi, une petite boîte noire contenant une carte mère Alix, avec un AMD Geode à 500Mhz, 256MB de mémoire, et un disque de 160GB. Son avantage est sa consommation réduite (moins de 10W), on peut difficilement trouver mieux aujourd'hui (mais bientôt avec la plateforme ARM probablement). Je me suis limité à faire tourner un service SMTP (mail), avec accès IMAP, ainsi qu'une messagerie XMPP (Jabber).

J'ai volontairement fait tourner ce serveur sur plusieurs OS différents au cours de sa vie, afin de pouvoir me former sur divers environnements. Linux m'étant déjà familier, c'est sur NetBSD et OpenBSD que j'ai le plus appris.

Linux (Debian)

Côté Linux, il faut déjà savoir que CentOS ne fonctionne pas car il requiert un processeur compatible i686. Or l'AMD Geode ne l'est pas, il est i586 optimisé i486 ! Il existe des astuces consistant à changer le kernel par défaut, mais je n'ai pas voulu me lancer là dedans.

J'ai commencé avec Debian Squeeze. Le CD d'installation est la version i386, mais l'installeur ira chercher le kernel i486 sur internet. Le matériel est correctement détecté, aucun problème n'est à signaler. Pour mon serveur SMTP j'ai utilisé Postfix, dont la configuration est aisée car il y a un assistant semi-graphique, et Dovecot pour l'accès IMAP. Concernant la messagerie XMPP j'ai récupéré les DEBS de Prosody sur leur site officielle.

On parle souvent de Debian comme d'un système compliqué, or selon moi c'est au contraire fait pour les flemmards. C'est très user-friendly pour l'administrateur, il y a vraiment peu de choses à faire. C'est robuste, facile à mettre à jour, riche en logiciels proposés, très puissant.

NetBSD

C'est avec ce système que j'ai plongé dans "l'univers des BSD", phrase qui est d'ailleurs un abus de langage car chaque système xBSD ne partage que la licence mais pas les mêmes composants. Par exemple Ubuntu et SuSE utilisent tous les deux du GNU et du Linux, sous le capot c'est donc "la même chose", alors que pour FreeBSD et NetBSD ce n'est pas le cas chacun ayant son kernel et son userspace.

J'ai voulu débuter avec FreeBSD, plus gros, plus vif, plus communautaire, mais il semblait y avoir un bug avec l'installeur et ma carte réseau. En attendant que la version 9.0 sorte, je suis donc passé à NetBSD.

Ce fut un peu la douche froide par rapport à Debian, car j'ai du apprendre à utiliser vi, ce qui peut faire sourire à première vue mais ce n'est vraiment pas facile au début. J'ai du apprendre le concept des ports (pkgsrc), ainsi que leur fonctionnement. Pour me dépanner, j'ai du apprendre à lire la doc officielle, ainsi que les pages man. Autant sur Linux on peut souvent trouver sur un forum la solution à un problème, autant sur NetBSD c'est rarement le cas.

La communauté IRC anglophone est très sérieuse, on sent qu'on a pas affaire à des rigolos venus montrer leur beau archlinux+openbox aux autres. A vrai dire je me suis souvent pris des "RTFM" dans la figure, et face à cela il y a deux réactions possibles :

• Soit on s'énerve et on leur hurle dessus que de toutes façons leur système c'est nul et on claque la porte avec un "je retourne sur Linux".
• Soit on réalise qu'on est pas dans le même monde, qu'on à affaire à des gens sérieux, et qu'on ferait mieux de se mettre un peu à bosser si on veut progresser.

Bien entendu, j'ai choisi la deuxième solution. J'ai donc rapidement obtenu un système fonctionnel et souple. J'ai mis en place un second serveur NetBSD, virtualisé, pour compiler les logiciels (pkgsrc) et les distribuer sur mon serveur principal par FTP.

Ce qui m'a un peu refroidi, en revanche, ce sont les mises à jour. Il n'y a pas d'apt-get upgrade comme sur debian. La procédure standard consiste à récupérer les sources à jour de l'OS, et les compiler. Dans le cas d'une nouvelle release on peut mettre à jour automatiquement depuis un CDROM bootable. Cela me parait un peu complexe, surtout dans le cas d'un serveur où je n'ai pas de lecteur CD ni même d'écran, et sur lequel je n'ai pas envie d'installer les outils de compilation ou récupérer des sources.

NetBSD est un système léger, robuste, portable, mais peut-être réservé à certaines applications comme le matériel embarqué ou exotique et moins à une architecture standard sur laquelle Linux est plus facile. Ce n'est bien sûr qu'un avis subjectif et c'est un environnement très riche à découvrir, au moins pour se former sur l'architecture pure des UNIX-like.

A lire : mes retours d'utilisation de NetBSD postés à l'époque où je l'utilisais.

OpenBSD

Mon passage sur OpenBSD a été motivé par la sortie (récente) de la version 5.0. Lorsque le serveur a booté pour la première fois, je me suis dit que j'avais face à moi l'OS réalisé par les gourous les plus connus en matière de sécurité informatique, et que j'allais sûrement devoir réapprendre pas mal de choses pour les faire proprement. Je savais aussi qu'il y a malheureusement bien peu de développeurs et que je devais m'attendre à de fortes régressions par rapport à Linux et NetBSD sur le support matériel.

J'ai été un peu moins dépaysé grâce à mon expérience acquise sur NetBSD. Je connaissais vi, les ports, le rc.conf (bien qu'il diffère un peu) j'avais déjà une certaine assurance. J'ai même décidé de mettre Postfix de côté pour me tourner vers OpenSMTPD en raison de la simplicité de sa configuration.

J'ai commencé à rencontrer des problèmes avec les ports, bien peu à jour, avec notamment un Prosody 0.7 alors que j'avais besoin d'une version plus récente. Après m'être bagarré avec le système, avoir envoyé un message sur la mailing, j'ai tenté de mettre moi-même à jour le port jusqu'à ce que je découvre que c'était déjà fait. C'est une version "testing", mais elle fonctionne.

Un autre problème que OpenBSD m'a posé est au niveau de la virtualisation. J'utilise Linux-KVM et VMware sur mon ordinateur, mais je rencontre toujours des soucis. Sur KVM, OpenBSD est lent au point que la décompression de l'archive des ports, qui pèse 22MB, prend plus d'une heure (montre en main). Sur VMware, ce sont les protocoles réseau qui sont lents à s'initialiser (HTTP, SSH...) je me prends donc des timeout à chaque fois que le script d'un port essaie de télécharger les sources d'un logiciel (alors que le ping est bon). Le dernier candidat est VirtualBox, que je n'ai pas testé.

Concernant le processus de mise à jour, je ne m'y suis pas encore attaqué, mais visiblement c'est faisable à partir du CDROM comme pour NetBSD.

La seule chose qui m'a vraiment plu sur OpenBSD est OpenSMTPD, car pour le reste j'ai trouvé beaucoup de contraintes par rapport à mes besoins. Cet OS est conçu pour favoriser la sécurité, mais je n'en ai vraiment pas besoin.

Conclusion

On dit que les administrateurs sont des feignants, qu'ils aiment se simplifier la vie, et c'est mon cas. Debian est le système le plus pratique pour mon usage, qui répond à tous mes besoins et qui fonctionne bien. Je n'ai pas vu d'intérêt à me compliquer la vie sur NetBSD et OpenBSD.

Néanmoins, les utiliser a été très formateur pour moi, et je ne souhaite absolument pas laisser penser qu'ils sont mauvais, bien au contraire. C'est fait par des gens sérieux, qui se moquent du prestige et se concentrent sur la qualité de leur produit. Ils ont leurs avantages, leurs usages, mais parmi les raisons que j'ai détaillé je retiens plutôt Debian.

Au final on utilise les mêmes services, alors autant se faciliter la mise en place et les mises à jour. Debian is the winner !

Après moins de deux mois de fonctionnement de mon serveur sous OpenBSD, je publie une conclusion. Cela peut paraitre court, mais ma période NetBSD a aidé, je connaissais déjà les bases de pas mal de choses. J'ai quand même fait face à beaucoup de soucis, avec les ports et la virtualisation.

Historique

• Découverte de OpenBSD
• Épisode 1
• Épisode 2
• Épisode 3
• Épisode 4
• Épisode 5
• Épisode 6

Résumé et conclusion

OpenBSD, réputé pour être intransigeant sur la sécurité, me faisait un peu peur au début. Je me suis dit que j'allais devoir réapprendre certaines choses pour les faire correctement, et que de manière générale le fonctionnement serait bien différent des autres systèmes. Il n'en est rien, l'installation et la configuration sont très simples à effectuer.

Pour la fonction SMTP j'ai adopté OpenSMTPD pour sa simplicité de configuration, délaissant temporairement Postfix. Si l'installation du daemon IMAP Dovecot s'est faite sans soucis, en revanche cela a été plus compliqué pour Prosody. En effet il n'était disponible qu'en version 0.7 dans les ports alors qu'il me fallait la 0.8.2. J'ai finalement trouvé une solution mais ça n'a pas été sans mal.

Mes premières impressions furent donc mitigées, mais j'ai en revanche vu des choses sympathiques comme les rapports journaliers par mail très complets, signalant même les éventuels défauts de configuration.

Il est à noter qu'OpenBSD n'aime pas la virtualisation. Sur KVM, cela se traduit par une lenteur incroyable, tandis que sur VMware ce sont les protocoles (HTTP, FTP...) qui font la tête. Cela ne facilite pas les choses, car on aime bien avoir une version virtuelle sous la main pour faire des essais ou une buildbox.

Pour mon usage, OpenBSD s'est donc révélé peu aisé, et seul OpenSMTPD me parait être un réel avantage par rapport aux autres. Attention, je ne souhaite absolument pas sous-entendre qu'il est mauvais, bien au contraire. Mais pour mon usage, relativement simple et peu contraignant, cela fait beaucoup de soucis inutiles.

Voilà mon besoin : parfois je ne suis pas chez moi, mais j'aimerais quand même accéder à mon bureau kubuntu, pour pouvoir lire mes mails, retrouver mon firefox avec ses favoris, etc. VNC est loin d'être satisfaisant en raison de la difficulté de trouver un serveur et un client qui sont fiables, mais aussi pour sa très mauvaise qualité d'affichage. Pour avoir une solution équivalente à RDP, il existe NoMachine NX.

Il s'installe sur votre poste Linux, et ne nécessite aucune configuration puisqu'il s'appuie sur SSH. Ensuite, côté client, Windows ou Linux, vous pouvez établir une session distante et retrouver votre bureau. La simplicité de mise en place et les possibilités sont intéressantes, si vous configurez l'écoute sur le port 443 vous pouvez même y accéder depuis votre entreprise à travers le proxy. NoMachine NX n'est pas libre, mais il existe un équivalent qui l'est : FreeNX. Seulement ce dernier ne semble plus supporté depuis 2008, et de mémoire il était plus difficile à configurer (utilisation d'un système de clés...)

Installation (ubuntu)

Commencer par installer OpenSSH sur votre ordinateur :

$ sudo apt-get install openssh-server

Pour pouvoir accéder à votre ordinateur depuis internet, assurez-vous d'avoir redirigé le bon port sur votre routeur ou *box. Je vous conseille de rediriger le 443 TCP de la box vers le 22 TCP de votre ordinateur. Pourquoi ? Simplement car si vous voulez vous connecter depuis votre entreprise, souvent il n'y aura que le 80 (HTTP) et le 443 (HTTPS) accessibles. Or SSH écoute sur le port 22. Cette redirection (PAT, Port Address Translation) est donc intéressante.

Récupérez ensuite la version Linux 32 ou 64 bits chez NoMachine Il y a DEB, RPM ou tarball. Nous allons prendre la version DEB. Prenez les 3 paquets (client, node, serveur). Téléchargez-les dans un répertoire.

$ ls
nxclient_3.5.0-7_amd64.deb  nxnode_3.5.0-7_amd64.deb  nxserver_3.5.0-9_amd64.deb
$ sudo dpkg -i *.deb
$ sudo apt-get -f install

Et voilà, c'est tout !

Connexion (Windows)

Rendez-vous sur la page de téléchargements de NoMachine NX et récupérez le "NX client for Windows". Installez-le. Vous allez ensuite avoir un assistant vous permettant de configurer l'accès à votre machine. Il y a peu de choses à compléter, et rien n'est compliqué.

En utilisant le bouton "Configure" il est possible de modifier pas mal d'options, comme la résolution que l'on souhaite, ou alors l'utilisation d'un Proxy (notamment HTTP avec authentification, ce qui est très pratique). Notez que ce bouton est grisé si vous lancez NoMachineNX avec le raccourci pointant directement sur votre session. Il faut alors utiliser le lanceur "générique" qui devrait lui aussi être sur le bureau.

Sur l'exemple ci-dessus, mon bureau kubuntu dans un Windows Seven. La connexion est très stable et complètement fiable même via internet (ligne ADSL). La qualité d'affichage varie selon la vitesse du réseau, mais l'intégration avec le système actuel est meilleure que VNC. Le bureau reste assez fluide, mais cela dépend bien sûr des décorations et éléments à charger. Le mieux est d'avoir une interface minimaliste comme Windows 98 avec fond d'écran uni. Mais ça n'est pas obligatoire.

Conclusion

NoMachine NX est un excellent produit pour accéder à son bureau de n'importe où, sans devoir emmener son ordinateur personnel avec soit. Il est facile à mettre en place, rapide, stable, que demander de plus ?

Dans la version stable des ports, Prosody n'est qu'en version 0.7.0. Après un petit message sur la mailinglist des ports j'ai découvert ça. Un dépôt git "openbsd-wip ports" (work in progress). Autrement dit, des versions "testing" de quelques ports, et notamment Prosody.

Donc pour récupérer Prosody 0.8.2, voici ce que j'ai fait (il y a peut-être d'autres solution) :

• Avoir un arbre des ports stable à jour, la procédure est ici.
• Installer devel/git (depuis les ports ou les packages)
• Récupérer les openbsd-wip ports avec la commande :

# git clone git://github.com/jasperla/openbsd-wip.git /usr/wip-ports

• Transférer le Prosody qui nous intéresse dans l'arbre des ports :

# rm -rf /usr/ports/net/prosody
# cp -R /usr/wip-ports/net/prosody /usr/ports/net/

• Lancer la compilation :

# cd /usr/ports/net/prosody && make install

• Profit.

Éventuellement, vous pouvez faire tout cela depuis une buildbox (machine de compilation/déploiement) et utiliser le commande make package pour créer des paquets. Ils seront situés dans /usr/ports/packages. Déployez-les sur le serveur en FTP, ou en les copiant à la main.

Notes

Quelques informations utiles :

• La configuration se fait dans /etc/prosody
• Les logs sont dans /var/prosody/
• Le data est aussi dans /var/prosody
• Les mots de passe sont stockés en clair par défaut

Fetchmail permet d'aller récupérer des messages sur un serveur distant et les rapatrier. C'est utile par exemple si vous venez de mettre en place votre propre serveur mail, et que vous voulez centraliser les messages que vous recevez sur vos différentes boîtes mails qui se situent chez d'autres hébergeurs.

Installation

Depuis les ports ou les packages. La deuxième solution est la plus simple :

# export PKG_PATH=ftp://ftp.openbsd.org/pub/OpenBSD/5.0/packages/i386/
# pkg_add -i fetchmail

Ensuite connectez-vous en tant qu'utilisateur non-root (fetchmail le déconseille) et créez un fichier de configuration .fetchmailrc dans son home. Par exemple, pour l'utilisateur dragonborn :

# su - dragonborn
$ vi ~/.fetchmailrc

Imaginons que nous voulons récupérer les mails de deux boites, pour deux destinataires. Les deux sont chez free dans mon exemple :

poll pop.free.fr proto pop3:
user "utman2004", with password "mypasswordhere", is "utman001@mylocalbox" here;
user "xavier.chotard", with password "mypasswordhere", is "xavier@mylocalbox" here;

Le rapatriement des messages se fait au lancement de la commande "fetchmail". On peut créer une tâche cron pour faire cela automatiquement...

$ crontab -e

Entrez :

@hourly fetchmail

Là c'est toutes les heures, mais vous pouvez modifier cette valeur...