J'ai une ATI X1400 en carte graphique, qui utilise le driver libre radeon sur Linux. Il est impossible de faire tourner beaucoup de jeux dans wine, notamment KOTOR, car les textures ne s'affichent pas. En effet, voilà ce qu'on obtient :

Après investigation, il s'avère que cela est du à l'absence d'une technologie de compression de textures appelée s3tc. Si elle n'est pas présente, c'est visiblement à cause d'un problème de brevets. Heureusement il est possible de l'avoir quand même.

Requis

Les forums et tutoriels que l'on trouve sur le web conseillent une version récente de Linux et de Xorg. J'utilise kubuntu 12.04 dans mon cas. Cela devrait être bon pour Ubuntu 11.10 aussi. Pour Debian Squeeze, on peut utiliser les backports, la procédure est décrite quelque part dans cette page.

Mise en place

Il faut commencer par récupérer les librairies s3tc, elles ne sont packagées nulle part, sauf sur le dépôt debian-multimedia. Pas besoin de l'ajouter, vous pouvez vous contenter de récupérer uniquement le paquet qui nous intéresse : version i386 ou version amd64. Ensuite, installez le paquet à coup de dpkg.

$ sudo dpkg -i nomdupaquet.deb

Utilisation

Essayez maintenant de lancer KOTOR. Il est à noter qu'il est nécessaire d'aller dans la configuration de wine (winecfg) et d'émuler un bureau virtuel (de la taille que vous voulez) car le jeu ne marche pas en plein écran. Si les textures ne sont toujours pas présentes, lancez wine avec le préfixe suivant :

$ force_s3tc_enable=true wine /chemin/vers/kotor/swkotor.exe

Si vous utilisez PlayOnLinux, la commande est la suivante :

$ force_s3tc_enable=true /usr/share/playonlinux/playonlinux --run "Star Wars Knights of the Old Republic"

Et voilà ce que vous devriez obtenir :

Vous pouvez maintenant jouer à KOTOR avec votre carte graphique AMD et son pilote libre !

On parle souvent en bien du constructeur AMD qui a généreusement libéré les spécifications de ses cartes graphiques, et poussé le développement d'un pilote libre.

Mais dans la pratique les choses ne sont pas aussi belles qu'on pourrait l'espérer, il faut être très patient avant qu'une carte soit supportée correctement par ce pilote libre. Mon HD5850, achetée fin 2009, n'a pas eu de début de support avant début 2010, et encore ce n'était que pour la résolution (en kernel mode setting). Mais il n'y avait pas d'accélération 2D ni 3D, on ne pouvait même pas lancer Stellarium. Et ce fut pareil pour le restant de l'année, ainsi qu'en 2011...

J'ai eu l'idée de jeter un coup d'oeil aujourd'hui, sur une Kubuntu daily (donc une 12.04) et ô surprise, la 2D & 3D sont enfin supportées. On peut donc profiter des effets graphiques de KDE, mais aussi lancer Stellarium qui tourne à 60FPS (avec fglrx on peut attendre 150).

SuperTuxKart, avec 19 karts IA, 1920x1080 plein écran est parfaitement jouable. On peut donc dire qu'une HD5850, et donc par extension les HD5000 series de chez AMD, sont enfin exploitables avec le pilote libre. Du moins elles le seront dans la prochaine génération de distributions Linux.

Proxmox VE - Virtual Environment - est une solution de virtualisation bare metal orientée entreprise prête à l'emploi, basée sur l'hyperviseur Linux-KVM et les containers OpenVZ. Sa particularité est de proposer une console graphique en web pour administrer le tout. La version 2 est actuellement en beta, mais sa sortie finale est prévue d'ici le mois de Mars (2012 Q1 d'après la roadmap).

Caractéristiques

L'entreprise Proxmox qui développe Proxmox VE met son produit à disposition gratuitement sous licence libre. Parallèlement à cela ils proposent du support payant (forums, assistance, requêtes aux développeurs...) et une solution de sécurisation de messagerie (mail gateway) payante, même si il existe une version free avec moins de fonctionnalités.

Proxmox VE permet de faire simplement un cluster avec plusieurs serveurs physiques, et depuis la version 2.0 la HA, High Availability (haute disponibilité) est possible. Il est donc envisageable d'assurer la continuité de service même en cas de panne matérielle. L'entreprise Proxmox dispose de certifications avec plusieurs constructeurs (la liste est visible dans leurs brochures commerciales).

Proxmox VE se base sur Debian 6.0 Squeeze amd64, avec un kernel "based on RHEL6x" et lui ajoute un dépôt permettant d'avoir l'interface web de configuration mais aussi une version de qemu à jour. Le fonctionnement en cluster fait appel au système de fichiers pmxcfs (Proxmox Cluster file system).

Installation

Vous devez commencer par télécharger l'ISO d'installation à cette adresse. Le processus est simple et ne demande que d'entrer un mot de passe root et de spécifier une adresse IP fixe. Le disque dur entier est automatiquement utilisé et formaté pour recevoir Proxmox. Après avoir démarré le système, vous pouvez lancer une mise à jour pour être certain d'avoir les dernières versions des composants. Vous pouvez le faire sur la machine même, ou par accès SSH de la manière suivante :

# apt-get update
# apt-get dist-upgrade

Découverte de l'interface

L'adresse IP de votre serveur Proxmox s'affiche lorsque celui-ci a fini de booter. Il y a également l'adresse de l'interface d'administration, elle est de la forme https et contient le FQDN ou l'adresse IP suivie du port 8006. Par exemple : https://10.40.1.17:8006

Cette vue affiche les principales informations de votre infrastructure : serveurs, authentification, configuration. Tout comme sur vSphere, le cadre du bas affiche les logs à la volée ce qui vous permet de connaître précisément les résultats de vos opérations sur l'hyperviseur. Dans le menu "storage" (stockage) vous pouvez voir vos différents périphériques : disque local, partage NFS, iSCSI. Stocker ses VM sur un support réseau permet de mettre en place la High Availability. La liste des serveurs à gauche permet d'accéder à une configuration individuelle : paramètres IP, nom d'hôte, etc.

Pour découvrir l'interface plus en détail et apprendre à mettre en place une machine virtuelle, Proxmox a créé une chaîne Youtube avec des tutoriels video. Voir les vidéos.

Virtualisation KVM vs container OpenVZ

Pour connaître le fonctionnement théorique de la virtualisation et des containers, je vous renvoie à cet ancien article dans lequel j'explique les différences entre les deux à l'aide de schémas.

OpenVZ est la solution la plus performante, puisqu'il n'y a aucune couche d'émulation et un seul kernel pour tous les systèmes invités. Il n'y a en pratique aucune perte de performance ou elle s'élève à seulement 2 ou 3%. Il faut cependant que le système invité soit de type Linux, puisqu'il sera dépourvu de kernel et utilisera celui de l'hôte. Pour cela, Proxmox VE utilise des templates (modèles). Il y a par exemple un template pour Debian Squeeze, qui va juste demander à l'utilisateur d'entrer un mot de passe root, les paramètres IP et l'installation se fera ensuite automatiquement. Le boot est presque instantané.

KVM va au contraire émuler un ordinateur complet afin de rendre le système indépendant de l'hôte. Cette virtualisation est assurée par le processeur de l'hôte (grâce aux instructions Intel VT-x ou AMD-V) et par Qemu pour la création des périphériques complémentaires. Il est ainsi possible d'installer des systèmes non modifiés tels que Windows, et d'utiliser des périphériques VirtIO (qui ne sont pas réellement émulés mais partagés avec l'hôte). Par contre SPICE, solution de virtualisation desktop développée par RedHat, ne semble pas encore disponible mais prévu.

Installation d'un Windows Server 2008 virtualisé

Je dispose d'un exemplaire de Windows Server 2008 en image iso (msdnaa). La première chose à faire est de l'envoyer sur le serveur. Pour cela, cliquez sur l'espace de stockage de votre choix dans la colonne de gauche. Dans l'onglet "content" vous verrez un bouton upload vous permettant d'envoyer votre iso. Il est aussi possible de le faire par SSH. Voir le tutoriel vidéo.

L'étape suivante consiste à créer une nouvelle machine virtuelle et à entrer les paramètres adéquats. Il est judicieux de sélectionner VirtIO pour le stockage et la carte réseau. Vous aurez cependant besoin de récupérer le CDROM de pilotes pour Windows. Vous pouvez suivre le tutoriel vidéo à cette adresse.

Attention, pour que la console fonctionne, vous devez avoir le plugin Java installé dans votre navigateur.

Une fois Windows 2008 installé, vous devrez aller dans le gestionnaire de périphérique pour installer les pilotes de la carte réseau (ils sont sur le CDROM VirtIO). Votre serveur virtualisé est maintenant prêt à l'emploi !

Conclusion

KVM, Linux, OpenVZ, sont des produits libres très puissants que l'on apprécie de voir fonctionner ensemble une fois leur configuration réalisée. Proxmox VE fournit un système où tout est déjà intégré, prêt à l'emploi. L'interface de configuration rend accessible à tous les administrateurs la mise en place de cluster de virtualisation, et rend ainsi cette solution compétitive avec celles du monde propriétaire.

Alors que Virt-Manager, développé par RedHat, est limité à Linux et tend à crasher très souvent, l'interface Web de Proxmox est universelle, stable, et bien plus complète.

Proxmox VE 2.0 est très bon !

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.